1 Einleitung und Zielsetzung

Die Idee für das Projekt TPTP-Web-TEST, im Folgenden kurz als Web-TEST bezeichnet, entstand durch den beruflichen Hintergrund des Autors der vorliegenden Arbeit. Der Autor, Günter Öller, ist als Webentwickler bei der Firma MathConsult GmbH [3] an der Entwicklung des Produkts UnRisk-FACTORY [4] beteiligt. UnRisk-FACTORY ist eine HTML-basierte Intranetanwendung. In dieser Webanwendung werden die HTML-Seiten von einem Webserver generiert. Im Folgenden wird diese Art von Anwendung als HTML-basierte Webanwendung bezeichnet.

UnRisk-FACTORY wird von Banken und anderen Finanzdienstleistern im Intranet eingesetzt, um den Wert von Finanzprodukten schätzen und überwachen zu können.

1.1 Problembeschreibung

Bei der Entwicklung von UnRisk-FACTORY ist es in der Vergangenheit oft zu Problemen gekommen. Neue Versionen des Produkts enthielten Fehler, die in Vorgängerversionen bereits ausgebessert waren, was unter anderem zu einer Verschlechterung des Produktimages führte. Das Problem ist, dass es bei Änderungen eines Dienstes oft zu Fehlern in einem anderen Dienst kommt. Abbildung 1.1 veranschaulicht dieses Problem.

Dienst B

Abbildung 1.1: Unerkannter Fehler durch eine neue Version der Anwendung

Wie Abbildung 1.1 darstellt, kann es durch eine Änderung eines Dienstes A zu einem Fehler in einem darauf aufbauenden Dienst B kommen, obwohl B nicht geändert und deshalb vielleicht nicht neu getestet wurde. Um dem vorzubeugen, kann man ein Testverfahren verwenden, das die unveränderten Dienste einer neuen Version mit der Vorgängerversion vergleicht. Diese Art des Testens wird als Regressionstesten bezeichnet und im Kapitel 2.3 „Regressionstests von HTML-basierten Webanwendungen“ näher beschrieben.

Für UnRisk-FACTORY wurde aufgrund dieses Fehlertyps entschieden, dass Regressionstests durchgeführt werden müssen. Um dies zu bewerkstelligen, wurde eine Mitarbeiterin als Tester eingesetzt, um die Vergleiche manuell durchzuführen. Da sich diese Arbeit als sehr zeitaufwendig und für den Tester demotivierend herausstellte, wurde dem Autor dieser Arbeit die Aufgabe übergeben, ein unterstützendes Testwerkzeug zu suchen.

Zu diesem Zweck wurden, unter anderem, folgende Werkzeuge getestet:

Rational Functional Tester von IBM [5]
NeoLoad von NeoTys [6]
vTest von Verisium [7]
eValid von Software Research [8]
JMeter von Apache [9]
BadBoy von Badboy [10]
PureTest von Minq Software [11]
das Open-Source Eclipse-Plug-In Solex [12]
die Open-Source Eclipse-Test-Plattform TPTP (Test and Performance Tools Platform) [13]

Bei der Evaluierung dieser Werkzeuge wurden jedoch folgende Punkte als unzureichend festgestellt:

Die professionelleren Werkzeuge sind auf Performanz- bzw. Last-Tests spezialisiert und bieten wenig Unterstützung für Funktions- und Regressionstests, die sich auf den Inhalt von HTML-Seiten beziehen.
Funktions- und Regressionstests im Webumfeld werden lediglich zum Überprüfen von HTTP-Response-Codes beziehungsweise einzelner Texte oder reguläre Ausdrücke in den HTML-Seiten verwendet.
Keines der getesteten Werkzeuge bot eine ausreichende Unterstützung bei der automatischen Erzeugung von Testbedingungen.

Zur Erklärung des letzten Punkts: UnRisk-FACTORY verwendet häufig HTML-Seiten mit einer zweispaltigen Tabelle wie in Abbildung 1.2 gezeigt, um Information anzuzeigen.

Abbildung 1.2: Zweispaltige Tabelle in UnRisk-FACTORY mit Attributen als Name-Wert-Paare

Wobei die erste Spalte den Namen eines Attributes und die zweite Spalte den dazugehörigen Wert enthält. Ein verwendbares Werkzeug muss diese Einheitlichkeit ausnützen und den Test für alle diese Attribute mit wenigen Schritten erstellen können. Eine bedeutende Randbedingung ist dabei, dass die Anzahl der nötigen Schritte nicht von der Anzahl der Zeilen in der angezeigten Tabelle abhängt.

Weiters wurden Werkzeuge getestet, die es erlauben, einen Schnappschuss einer HTML-Seite aufzuzeichnen und diesen Schnappschuss dann mit der Testausführung zu vergleichen. Dieser Bildvergleich hat jedoch den Nachteil, dass sich kein Parameter einer Seite ändern darf, damit der Tests erfolgreich verläuft. In UnRisk-FACTORY und in vielen ähnlichen Anwendungen wird jedoch ein Änderungsdatum angezeigt, dass sich von Testaufnahme zu Testausführung verändert.

Eine weitere Alternative sind Testwerkzeuge, die es gestatten, eine maximale Veränderungsrate anzugeben. Diese Rate gibt an, zu wie viel Prozent sich eine HTML-Seite von der Aufzeichnung zur Testausführung verändern darf. Leider wurde auch dieses Verfahren als unzulänglich für UnRisk-FACTORY eingestuft. Beim Testen von UnRisk-FACTORY ist es wichtig, den Wert bestimmter Felder genau zu überprüfen, andere Felder, wie etwa ein Änderungsdatum, sollen hingegen nicht überprüft werden.

Da keines dieser Werkzeuge überzeugen konnte, entschied sich MathConsult, die Tests weiter manuell durchzuführen. Der Autor dieser Arbeit wurde allerdings durch den Evaluierungsprozess auf die Eclipse-Test-Plattform TPTP aufmerksam. Dieses Framework bietet bereits die grundlegenden Dienste zum Durchführen von Regressionstests. TPTP unterstützt sowohl das Aufzeichnen von Verwendungsszenarien von HTML-basierten Webapplikationen, als auch das Verwalten und Abspielen dieser Szenarien. Im Wesentlichen fehlen lediglich die Funktionen, um Testbedingungen für den Inhalt von HTML-Seiten zu verwalten und diese während der Testausführung zu überprüfen. Da TPTP darauf ausgerichtet ist Erweiterungen zu ermöglichen, und der Quellcode unter der Eclipse-Public-Licence (EPL) [14] zur Verfügung steht, ist es möglich, die fehlenden Dienste hinzuzufügen. Aufgrund dieser Überlegung wurde das Projekt TPTP-Web-TEST gestartet.

1.2 Ziel des Projekts TPTP-Web-TEST

Im Rahmen des Projekts TPTP-Web-TEST sollen drei Ziele miteinander vereint werden:

Es soll ein Testwerkzeug für Regressionstests von HTML-basierten Webanwendungen erstellt werden. Das Unternehmen MathConsult GmbH soll durch dieses Werkzeug beim Regressionstesten der Anwendung UnRisk-FACTORY unterstützt werden.
Das Testwerkzeug soll auch für andere HTML-basierte Webanwendungen einsetzbar sein und von den jeweiligen Benutzern angepasst werden können.
Das Testwerkzeug soll sich in TPTP integrieren und neue Versionen von TPTP unterstützten. Deshalb muss die Entwicklung von Web-TEST mit dem TPTP-Team abgesprochen werden.

1.2.1 Die Anforderungen an Web-TEST

Die Firma MathConsult benötigt ein Werkzeug, das den in Abbildung 1.3 dargestellten Anwendungsfall zum Testen von UnRisk-FACTORY unterstützt.

Abbildung 1.3: Geforderter Anwendungsfall für Web-TEST

Abbildung 1.3 zeigt, aus welchen Schritten der geforderte Testprozess besteht:

Der Tester nimmt eine zu gewährleistende Funktionalität auf. Dazu spielt er diese Funktionen in der zu testenden HTML-basierten Webapplikation durch und lässt einen Prozess mitlaufen, der alles protokolliert.
Der Tester bearbeitet den so erstellten Test. Er führt Variablen für die Testausführung ein und legt Testbedingungen für den Inhalt von HTML-Seiten fest.
Ein Benutzer (der Tester selbst oder ein Entwickler) kann durch Umstellen der Applikations-URL den Test mit verschiedenen Versionen der Applikation abspielen.
Nach der Beendigung einer Testausführung kann sich der Benutzer den Testbericht anzeigen lassen.

Wesentlich ist der Schritt 2, in dem die Testbedingungen erstellt werden. Gerade in diesem Punkt muss sich Web-TEST von den evaluierten Testwerkzeugen unterscheiden. Folgende Funktionen müssen angeboten werden:

Es muss möglich sein, eine Bedingung für den Inhalt eines speziellen Elements einer HTML-Seite zu erstellen.
Es muss möglich sein, Bedingungen für alle HMTL-Seiten mit gleicher Struktur aber unterschiedlichen Inhalten in einem Schritt zu generieren.

Die letzte der beiden hier angesprochenen Funktionen hilft dem Tester von UnRisk-FACTORY außerordentlich. Wie zuvor schon erwähnt, zeigt UnRisk-FACTORY sehr viele Informationen über zweispaltige Tabellen an. Wobei jede Zeile eine Eigenschaft eines in UnRisk-FACTORY verwendeten Objekts beschreibt. Jede Eigenschaft hat einen Namen und einen Wert. Bei der Testausführung müssen dann die Objekteigenschaften die gleichen Werte wie bei der Testaufnahme haben.

Abbildung 1.4: Objekteigenschaften einer Testvorlage und einer Testausführung in UnRisk Factory

Abbildung 1.4 zeigt zweimal den gleichen Ausschnitt einer HTML-Seite von UnRisk-FACTORY. Dabei wird auf der linken Hälfte der Zustand dargestellt, der in einer älteren UnRisk-FACTORY Version als richtig festgehalten wurde. Auf der rechten Hälfte wird der Zustand der HTML-Seite dargestellt, der beim manuellen Durchführen eines Regressionstests mit einer neuen Version von UnRisk-FACTORY angezeigt wird. Wenn man die Zeilen der dargestellten Tabellen vergleicht, dann erkennt man, dass diese bis auf die Zeile „Modification Date“ identisch sind. Somit ist der manuelle Regressionstest erfolgreich verlaufen. Wenn man das tatsächlich und gewissenhaft macht, dann bemerkt man schnell, dass das manuelle Überprüfen der Werte sehr zeitaufwendig und fehleranfällig ist. Unter anderem fehleranfällig, weil man bei der großen Anzahl der Zeilen und den oft ähnlichen Werten leicht etwas übersieht. Weiters ist zu beachten, dass es hunderte verschiedene Objekttypen und damit hunderte dieser Tabellen in UnRisk-FACTORY gibt, die getestet werden müssen.

Die automatische Erzeugung der Testbedingungen aus der Testvorlage und der programmgesteuerte Vergleich während der Testausführung sind deshalb eine wesentliche Erleichterung für den Tester. Dabei wird nicht nur der Tester entlastet, sondern auch die Qualität des Tests gesteigert.

1.3 Aufbau der Arbeit

Diese Arbeit beschreibt die Umsetzung der zuvor beschriebenen Anforderungen im Rahmen des TPTP-Web-TEST-Projekts und ist inhaltlich wie folgt aufgebaut:

§ In Kapitel 2 „Methoden zum funktionalen Testen von HTML-basierten Webanwendungen“ werden die verwendbaren Testmethoden vorgestellt, und es wird festgelegt, welche Testmethode das Werkzeug Web-TEST verwendet.

§ In Kapitel 3 „Die Verwendung von Web-TEST“ wird das Werkzeug Web-TEST aus Benutzersicht vorgestellt. Mit Hilfe eines Anwendungsfalls wird demonstriert, wie ein Benutzer Web-TEST verwendet.

§ In Kapitel 4 „Das TPTP-Framework“ wird das von Web-TEST verwendete Eclipse-Test-Framework TPTP vorgestellt.

§ In Kapitel 5 „Die Umsetzung von Web-TEST“ werden die Umsetzung und die Schnittstellen von Web-TEST besprochen.

§ In Kapitel 6 „Ausblick und Schlussfolgerung“ wird ein Überblick über mögliche Erweiterungen gegeben. Abschließend wird in diesem Kapitel die persönliche Einschätzung des Autors für das Werkzeug Web-TEST dargelegt.

1.3.1 Die Verwendung von Fachausdrücken, Abkürzungen und Fremdwörtern

Gebräuchliche und in der Informatik übliche Fachausdrücke, Abkürzungen und Fremdwörter werden im Text nicht speziell gesetzt und es wird kein Glossar aller verwendeten Ausdrücke angeboten. Nicht gebräuchliche und in der Informatik unübliche Fachausdrücke, Abkürzungen und Fremdwörter werden bei ihrer ersten Verwendung im Text erklärt oder mit einem Literaturverweis versehen. Weiters werden diese Ausdrücke bei ihrer ersten Verwendung in kursiver Schrift gesetzt. Bei jeder weiteren Verwendung werden diese Ausdrücke nicht nochmals erklärt und sie werden dann nicht mehr speziell gesetzt. Zusammengesetzte Fremdwörter und Eigennamen werden mit Bindestrich dargestellt. Außerdem wird bei der ersten Übersetzung eines englischen Begriffs (beispielsweise aus Tabellen, Grafiken oder von Fachbegriffe) die englische Form in Klammer nach der Übersetzung notiert. Diese Notation wird auch verwendet, wenn im Text Synonyme für Begriffe aus Tabellen und Grafiken benutzt werden. Namen von Elementen in grafischen Oberflächen (Labels), Ordnernamen, Pfade und Werte von Attributen aus Grafiken und Tabellen werden mit Hilfe von Anführungszeichen gekennzeichnet.

2 Methoden zum funktionalen Testen von HTML-basierten Webanwendungen

Das Testen von Webanwendungen stellt sich aufgrund der oft mehrschichtigen Architektur etwas komplexer dar als bei normalen Desktop-Anwendungen. Auch UnRisk-FACTORY ist eine mehrschichtige Webanwendung, wobei die in Abbildung 2.1 dargestellte dreischichtige Webarchitektur verwendet wird.

Textfeld: Storage System

Abbildung 2.1: Die Standard-Drei-Schichten-Webarchitektur

Abbildung 2.1 zeigt die Standard-Drei-Schichten-Webarchitektur. Diese besteht aus Datenhaltung (Storage System), Geschäftslogik (Business Layer) und Webserver (Web Server). Die einzelnen Schichten sind hierarchisch angeordnet und voneinander abhängig. Daraus ergibt sich auch, dass ein stufenweises Testverfahren benötigt wird, um zuerst die Einzelkomponenten und später das Gesamtsystem testen zu könne. Das Testen von Webanwendungen wird deshalb, wie bei komplexen Software-Projekten üblich, in mehrere Phasen unterteilt [1]:

Test der Spezifikation (Requirement Testing): Testen der Spezifikation auf Widerspruchsfreiheit, Vollständigkeit und Klarheit.
Modultest (Unit Testing): Testen von einzelnen Klassen und später Modulen für sich selbst.
Integrationstest (Integration Testing): Testen des schrittweisen Zusammenfügens der einzelnen Module.
Systemtest (System Testing): Testen des Gesamtsystems unter realen Bedingungen.
Abnahmetest (Acceptance Testing): Ein Kunde oder ein Anwender testet das System gegenüber der Spezifikation. Gegebenenfalls werden dabei auch Änderungen an der Spezifikation durchgeführt.
Regressionstest (Regression Testing): Diese Testphase wird bei der Weiterentwicklungen von Software verwendet. Dabei wird getestet, ob eine neue Version einer Software die Kontrakte der Vorgängerversion noch erfüllt.

In den einzelnen Phasen können verschiedene Testmethoden eingesetzt werden. Dabei unterscheidet man zwischen zwei Kategorien [1]:

Statische Testmethoden: Tests die ohne das Ausführen des zu testenden Programms - im Folgenden kurz als SUT (Software under test) bezeichnet – durchgeführt werden können. Beispiele dafür sind: Schreibtischtests, Code-Inspektionen, Walkthroughs und Checklisten.

Dynamische Testmethoden: Diese Tests führen das Programm tatsächlich aus. Dabei werden Ergebnisse und Parameter mit Vorgabewerten verglichen. Dynamische Testmethoden werden wieder in zwei große Klassen unterteilt: White-Box-Testing und Black-Box-Testing.

2.1 White-Box-Testing

Das White-Box-Testing wird vor allem verwendet, um in frühen Phasen der Entwicklung das korrekte Verhalten einzelner Komponenten zu gewährleisten.

Abbildung 2.2: Das White-Box-Testing-Prinzip

In Abbildung 2.2 wird das Prinzip des White-Box-Testings dargestellt. Der Tester hat dabei die vollständige Information über die innere Struktur der Software. Deshalb wird diese Testmethode auch als strukturelles Testen bezeichnet. Auch die Auswahl der Testfälle wird mit Hilfe der Kenntnis der inneren Struktur durchgeführt. Dabei haben sich drei Alternativen etabliert [1]:

Die Testfälle werden so ausgewählt, dass jede Anweisung zumindest einmal ausgeführt wird.
Die Testfälle werden so ausgewählt, dass jede Bedingung zumindest einmal auf wahr und einmal auf falsch gesetzt ist.
Die Testfälle werden so gewählt, dass jeder Pfad zumindest einmal ausgeführt wird.

Wobei die Alternative drei das „stärkere“ Auswahlkriterium für Testfälle ist. Diese Alternative bedeutet, dass unter anderem alle Schleifen bis zur maximalen Durchlaufsgrenze ausgeführt werden müssen. Da diese Bedingung oft zu unendlich vielen Testläufen führen würde, ist sie nicht vollständig realisierbar.

White-Box-Testing wird vor allem für das Unit-Testing verwendet. Dabei werden die Tests meist vom Entwickler selbst erstellt. Dieser hat Kenntnis über den zu testenden Quellcode. Das Prinzip dabei ist, zuerst die kleinsten Einheiten mit vollständiger Kenntnis des Quellcodes zu testen und dann kontinuierlich zu größeren Einheiten und dafür zu weniger Kenntnis der internen Struktur überzugehen. Schließlich kennt der Tester – nicht mehr der Entwickler selbst - nur mehr die Schnittsellen zwischen den einzelnen Komponenten und man hat die Integrationstestphase erreicht.

2.2 Black-Box-Testing

Das Black-Box-Testing wird verwendet, um die Spezifikation und die Umsetzung zu vergleichen. Dabei ist keine Kenntnis der internen Programmstrukturen nötig [1].

Abbildung 2.3: Das Black-Box-Testing-Prinzip

In Abbildung 2.3 wird das Prinzip des Back-Box-Testings dargestellt. Der Tester überprüft, ob die Software die in der Spezifikation geforderten Aufgaben richtig erfüllt. Dabei wird keine Information über die innere Struktur der Software benötigt. Die Auswahl der Testfälle wird deshalb ausschließlich mit Hilfe der Spezifikation durchgeführt. Aus der Spezifikation werden alle benötigen Funktionen ermittelt und alle dafür möglichen Eingaben in Eingabeklassen eingeteilt. Für ein Ganzzahlenfeld würden standardmäßig folgende vier Eingabeklassen entstehen:

Gültige Eingabe größer 0
Gültige Eingabe gleich 0
Gültige Eingabe kleinern 0
Ungültige Eingabe

Theorietisch reicht es für jede der gültigen Eingabeklassen einen Testfall für die zu testenden Funktion zu erstellen. Es ist jedoch üblich zumindest drei Testfälle pro gültige Eingabeklasse zu erstellen. Dabei werden meist die untere und die obere Grenze der Klasse und ein Wert aus der Mitte der möglichen Werte genommen. Für die Klasse der ungültigen Eingaben gilt jedoch: je mehr Testfälle desto besser [1].

Black-Box-Testing hat drei wesentliche Vorteile gegenüber dem White-Box-Testing [1]:

Die Tests basieren auf der Spezifikation und nicht auf der Umsetzung. Dadurch werden Missverständnisse zwischen Spezifikation und Programmierung erkannt.
Die Tests bleiben großteils unabhängig von der Implementierung und sind deshalb auch nach einer Änderung der Implementierung noch verwendbar.
Die Tests können sich auf die, in der Spezifikation als wesentlich festgehaltenen, Funktionen konzentrieren.

Diesen Vorteilen stehen folgenden Nachteile des Black-Box-Testings gegenüber:

Black-Box-Testing kann nicht vollständig sein, weil es normalerweise eine unendliche Menge an verschiedenen Eingaben für eine Funktion gibt.
Black-Box-Testing erkennt keine Implementierungsschwachstellen, wie beispielsweise nicht erreichbaren, unnötigen Code.
Beim Black-Box-Testing ist der Quellcode nicht bekannt, deshalb können besonders komplexe Methoden nicht intensiver getestet werden.
Black-Box-Testing ist erst möglich, wenn die zu testende Funktion vollständig ausführbar ist.

Es ist bei beiden Methoden wichtig, dass die erwarteten Testergebnisse vor der Testausführung festgelegt werden. Manchmal können die Ergebnisse von Testfällen direkt aus der Spezifikation beziehungsweise aus der Funktionsbeschreibung abgeleitet werden. Wenn dies nicht möglich ist, müssen die Ergebnisse von einem Orakel, entweder einem menschlichen Experten oder einem anderen Programm, vorhergesagt werden.

2.3 Regressionstests von HTML-basierten Webanwendungen

Eine andere Methode um die erwarteten Ergebnisse vorhersagen zu können, bieten Tests, bei denen die erwarteten Ergebnisse durch eine Vorgängerversion der SUT festgelegt werden. Diese Art des Testens zählt zu der Kategorie der Regressionstests. Als Software-Regressionstests werden alle Software-Tests bezeichnet, die versuchen festzustellen, ob ein Kontrakt der Spezifikation, der in einer Vorgängerversion der SUT bereits erfüllt war, in der aktuellen Version noch erfüllt wird. [1]

Diese Methode nutzt dabei die Eigenschaft von Software-Produkten, dass von einer Version einer Software auf die nächste der Großteil der Spezifikation gültig bleibt. Deshalb können die Tests und die erwarteten Ergebnisse der Vorgängerversion übernommen werden. Im Endeffekt müssen nur mehr die Neuentwicklungen und die Änderungen die ersten fünf zuvor in Kapitel 2 beschriebenen Testphasen durchlaufen. Der Großteil der Spezifikation muss lediglich die bereits existierenden Regressionstests passieren. Mit Hilfe von Regressionstests kann also sehr viel Zeit eingespart werden.

Regressionstests können sowohl White-Box-Tests als auch Black-Box-Tests sein [2]. In der Regressionstestphase werden deshalb sowohl die bereits existierenden Unit-Tests als auch die automatisierten Abnahmetests ausgeführt.

Das in dieser Arbeit entwickelte Werkzeug Web-TEST unterstützt die Erstellung und Wartung von Regressionstests und die automatische Ableitung der erwarteten Ergebnisse aus einer Vorgängerversion der SUT und kombiniert diesen Testansatz mit dem Black-Box-Testing-Prinzip. Web-TEST konzentriert sich also auf die Wiederverwendung der Abnahmetests. Dabei wird vor allem auf folgende Punkte geachtet, um die Vorteile von Regressionstests und Black-Box-Testing auch wirklich an den Tester weitergeben zu können:

Geringe Abhängigkeit zwischen dem Quellcode der SUT und der Testdefinition. Die Testdefinition bezieht sich ausschließlich auf die HTTP- und die HTML-Schnittstelle der SUT.
Einfache Generierung der Testfälle durch Aufzeichnen von Testdefinitionen während der Benützung der SUT. Dabei werden sowohl die zu testenden Funktionen (HTTP-Requests), die Eingaben (HTTP-Parameter), und auch gleich die Ergebnisse (HTTP-Responses inklusive der HTML-Seiten) aufgezeichnet. Die erwarteten Ergebnisse für spätere Versionen der SUT (Bedingungen für die Responses) können dann mit Hilfe der aufgezeichneten Responses generiert werden.
Möglichkeit der Automatisierung der Testausführung nach Fertigstellung einer neuen Version, beispielsweise über Ant-Skripts [15].

Dem Gegenüber stehen folgende Nachteile von Web-TEST und der Regressionstests im Allgemeinen:

Das Testen von neuen Funktionen gestaltet sich eher aufwendig und sollte entweder mit Hilfe eines anderen Werkzeugs oder weiter manuell durchgeführt werden.
Weiters ist es nicht möglich neue Funktionen zu testen, bevor sie nicht in der Benutzeroberfläche – der HTML-Schnittstelle - realisiert sind.
Änderungen in der Spezifikation bewirken, dass bereits erstellte Regressionstests für neue Versionen der SUT ungültig werden und neu erstellt oder geändert werden müssen.

3 Die Verwendung von Web-TEST

Dieses Kapitel betrachtet das Werkzeug Web-TEST aus der Sicht des Benutzers. Einleitend wird beschrieben, wie Web-TEST installiert und konfiguriert wird. Dann wird ein umfassender Anwendungsfall durchgespielt, der die wesentlichen Funktionen und Konzepte von Web-TEST darstellt.

Folgende Voraussetzungen sind für das Verständnis dieses Kapitels erforderlich:

Erfahrung mit Eclipse [16].
Erfahrung mit dem HTTP-Protokoll und Kenntnis des HTTP-Request-Response-Zyklus [17].
Grundlegende Kenntnisse über HTML [18].
Grundlegende Kenntnisse über XML und XPath [19].
Erfahrung mit den Testmethoden für Webanwendungen [siehe 1 und 2] beziehungsweise Verständnis des Kapitels 2 „Methoden zum funktionalen Testen von HTML-basierten Webanwendungen“.

3.1 Installation von Web-TEST

Für die Installation von Web-TEST ist eine vorhergehende Installation von Eclipse und TPTP 4.5.1 oder höher erforderlich. Näher Details zur Installation dieser Voraussetzung findet man unter [20]. Web-TEST steht als Eclipse-Feature zum Download unter https://sourceforge.net/projects/tptpwebtest/ zur Verfügung. Ein Eclipse-Feature ist eine Sammlung von Eclipse-Plugins, die nur in Kombination sinnvoll funktionieren. Das Eclipse-Feature für Web-TEST wird als Zip-Datei heruntergeladen. Die Zip-Datei muss dann in den Eclipse-Installationsordner entpackt werden, um die Installation fertig zu stellen. Dabei werden ältere Versionen von Web-TEST ersetzt. Danach muss Eclipse mit der Option „-clean“ neu gestartet werden, damit die Änderungen übernommen werden.

Nach der Installation wird im About-Eclipse-SDK-Dialog, zu finden im Menu „Help/About Eclipse SDK“, das Web-TEST-Icon () angezeigt. Abbildung 3.1 zeigt diesen Dialog.

Abbildung 3.1: About-Eclipse-SDK-Dialog mit Web-TEST-Icon

Wenn man auf das Web-TEST-Icon klickt, bekommt man die Information, welche Eclipse-Features und –Plug-Ins zu Web-TEST gehören und unter welcher Lizenz Web-TEST verfügbar ist. Abbildung 3.2 zeigt den Dialog, der erscheint wenn man auf das Web-TEST-Icon klickt und Abbildung 3.3 zeigt den Dialog, der die Web-TEST-Plug-Ins auflistet.

Abbildung 3.2: About-Eclipse-SDK-Feature-Dialog für Web-TEST

Abbildung 3.3: Feature-Plug-Ins-Dialog für Web-TEST

Web-TEST kann ebenfalls über den Eclipse-Update-Manager [22] installieren werden. Die dafür nötige Eclipse-Update-Site ist unter http://tptpwebtest.sourceforge.net/ verfügbar.

Alle Funktionen von Web-TEST werden dem Benutzer über die Eclipse-Perspektive „Test“ zur Verfügung gestellt. Zu finden ist diese Perspektive, ausgehend von einer englischen Eclipse-Installation, unter dem Menu „Window/Open Perspective/Other …/Test“ ().

3.2 Konfiguration von Web-TEST

Bevor man jetzt einen Test erstellen kann, müssen einige Einstellungen gesetzt werden und ein Java-Projekt muss erzeugt werden. Diese Konfigurationen müssen nur einmal nach der Installation von Web-TEST durchgeführt werden.

Folgende Vorbereitungen sind notwendig:

Testen des Agent-Controllers (eine Erklärung des Agent-Controllers folgt)
Konfigurieren eines Web-Browsers und eines Proxy-Ports mit denen Tests aufgenommen werden
Einstellen eines Inhaltsfilters
Anlegen eines Java-Projekts

3.2.1 Testen des Agent-Controllers

Der Agent-Controller ist ein eigener Dienst, der vom TPTP-Framework zur Verfügung gestellt wird. Er wird von TPTP unter anderem zum Aufnehmen der Tests verwendet. Dieser Dienst muss auf dem Rechner, auf dem der Test aufgenommen werden soll, laufen. Deshalb muss man überprüfen, ob dieser Dienst auf diesem Rechner ausgeführt wird und richtig auf Anfragen reagiert. Dazu kann die Funktion „Test Connection“ in der Eclipse-Einstellungsseite „Test“ ausgeführt werden. Abbildung 3.4 zeigt die Eclipse-Einstellungsseite „Test“. Diese Eclipse-Einstellungsseiten findet man unter dem Menüpunkt „Window/Preferences“.

Abbildung 3.4: Testen des Agent Controllers

Die Antwort, die man nach klick auf den Link bekommt, muss der Nachrichtenbox in Abbildung 3.4 entsprechen. Es muss also der Text „Connection success.“ angezeigt werden. Im Fehlerfall lassen sich die Einstellungen für den Agent-Controller in der Einstellungsseite „Agent Controller/Integrated Agent Controller“ anpassen - wie in Abbildung 3.5 dargestellt.

Abbildung 3.5: Konfigurieren des Agent Controllers

Die genaue Konfiguration des Agent-Controllers ist Teil von TPTP und kann in der Dokumentation von TPTP unter [13] nachgelesen werden.

3.2.2 Konfiguration eines Browsers und eines Proxy-Ports

Nach dem erfolgreichen Test des Agent-Controllers muss man Web-TEST bekannt geben welcher Browser für die Testaufzeichnung verwendet wird.

Abbildung 3.6: Konfiguration des Browser für die Testaufnahme

Diese Konfiguration kann auf der Einstellungsseite „Test/TPTP URL/URL Recorder“ durchgeführt werden. Die Abbildung 3.6 zeigt die Konfiguration des Mozilla-Firefox-Browsers zur Aufnahme. Weiters kann hier der Port für den Proxy-Dienst eingestellt werden. Der von TPTP vorgeschlagene Port ist 1080. Es kann jedoch jeder freie Port für diesen Dienst verwendet werden. Der Proxy-Dienst ist Teil des Agent-Controllers und wird zum Aufzeichnen eines Tests benötigt.

Abbildung 3.7: Der Proxy-Dienst zum Aufzeichnen von Testdaten

Wie Abbildung 3.7 zeigt, wird der Proxy-Dienst zwischen dem Browser und der SUT geschoben und zeichnet alle Nachrichten auf.

Zu beachten ist, dass es Unterschiede in der Verwendung verschiedener Browser innerhalb von TPTP gibt. Beispielsweise werden die Proxy-Einstellungen im Internet-Explorer automatisch übernommen, während Firefox diese nicht übernimmt. Dafür hat der Internet-Explorer ein Problem, wenn auf den Server „localhost“ zugegriffen wird. In diesem Fall ignoriert er die Proxy-Einstellungen. Um dennoch eine Anwendung auf „localhost“ aufzeichnen zu können, kann man sich mit dem Work-around „localhost.“ (sprich: „localhost-punkt“) abhelfen. In Firefox muss der Proxy hingegen manuell definiert werden und wird dafür auch bei „localhost“ verwendet.

Abbildung 3.8: Konfiguration des Proxies in Mozilla Firefox

Die Proxy-Einstellungen können in Firefox unter dem Menüpunkt „Extras/Einstellungen…/Erweitert/Netzwerk/Einstellungen…“ festlegt werden. In Abbildung 3.8 wird dargestellt, wie der Proxy für die Standardkonfiguration von Web-TEST eingestellt werden muss. Dabei wird ein „SOCKS v4“-Proxy auf „localhost“ und Port „1080“ eingetragen. Um den Proxy für andere Browser einzustellen kann die Hilfe des jeweiligen Browsers verwendet werden.

3.2.3 Einstellen des Inhaltsfilters und Anlegen des Java-Projekts

Um unnötige Testdaten zu vermeiden kann ein Inhaltsfilter für das Generieren der Testressource in Web-TEST definiert werden. Beispielsweise ist es aufgrund der Eigenschaften der Assertions sinnvoll, nur HTML-Antworten zu speichern.

Abbildung 3.9: Content Filter

Abbildung 3.9 zeigt die Einstellungsseite „Test/Web-TEST“, in der dieser Filter definiert wird. In diesem Beispiel ist der Filter auf „text/html“ gesetzt. Dadurch werden nur die Requests, die HTML-Seiten als Antwort haben, in die TPTP-Testressource übernommen. Die TPTP-Testressource (oder kurz die Testressource) ist die Ressource, die die gesammelte Testbeschreibung enthält. Diese Ressource wird in TPTP durch eine XML-Datei realisiert.

Weiters zeigt Abbildung 3.9 drei weitere Eingabefelder: „Execution – Host“, „Execution – Port“ und „Execution – Context“. Diese können dazu verwendet werden, um bei der Testausführung den Host, den Port und den Kontext der Requests zu überschreiben. Dadurch kann der Tests auf eine andere Version der SUT (unter einer anderen URL als bei der Testaufnahme) ausgeführt werden.

Bevor man nun beginnen kann einen Test zu erstellen, muss man noch ein Java-Projekt anlegen. Dies ist erforderlich, weil die Testressource später in eine JUnit-Klasse umgewandelt wird, damit der Test ausgeführt werden kann. Für den hier folgenden Anwendungsfall wird das Java-Projekt „Demo_WebTEST“ benannt und alle anderen Standardeinstellungen des Java-Project-Wizards beibehalten. Der Java-Project-Wizard ist der Eclipse-Wizard der zum Anlegen von Java-Projekten verwendet werden kann.

Nun ist Web-TEST installiert und vollständig konfiguriert und kann verwendet werden.

3.3 Ein Anwendungsfall für Web-TEST

Der folgende Anwendungsfall stellt alle wesentlichen Funktion von Web-TEST vor. Üblicherweise durchläuft der Benutzer von Web-TEST sechs Phasen um eine HTML-basierte Webanwendung zu testen. Diese Phasen werden im Rahmen des Anwendungsfalls in einzelnen Unterkapiteln beschreiben:

Aufzeichnen eines Tests.
Bearbeiten des aufgezeichneten Tests.
Erstellen von Bedingungen für das Ausführen des Tests (im Folgenden als Assertions bezeichnet).
Bearbeiten der Assertions.
Festlegung von dynamischen Request-Parametern. Siehe Kapitel 3.3.5 für eine detaillierte Erklärung der dynamischen Request-Parameter.
Programmgesteuertes Abspielen des Tests (mit einer anderen Version der SUT) und automatische Kontrolle der Ergebnisse.

3.3.1 Aufzeichnen eines Tests

Der Tester verwendet die SUT ganz normal, um einen Test aufzuzeichnen. Während der Verwendung der SUT läuft im Hintergrund ein Prozess, der alle Eingaben (Requests) und die darauf folgenden Ausgaben (Responses) aufzeichnet. Web-TEST bietet zum Steuern dieses Prozesses die Recorder-Ansicht (Recorder-Control). Diese wird in der Eclipse-Test-Perspektive im unteren Bereich der Benutzeroberfläche dargestellt.

Abbildung 3.10: Die Recorder-Ansicht

Abbildung 3.10 zeigt die Recorder-Ansicht nach einer erfolgreichen Aufnahme. Die beiden Buttons rechts oben ermöglichen es, eine Aufnahme zu starten () und zu stoppen (). Im Feld „KBytes Recorded“ wird die Größe der aufgenommen Daten angezeigt. Das Feld „Recorder Status“ zeigt den aktuellen Status der Aufnahme an und im darunter liegenden Textfeld werden detaillierte Statusnachrichten ausgegeben.

Abbildung 3.11: Der Testaufzeichnungs-Wizard erste Seite

Beim Starten der Aufnahme über den Button der Recorder-Ansicht wird der in Abbildung 3.11 dargestellte Wizard aufgerufen. Dieser erlaubt auf der ersten Seite folgende Einstellungen:

Testaufnahme: Soll der Test neu aufgenommen werden oder soll die Testressource mit Hilfe einer bereits existierenden Recorder-Datei erzeugt werden? Der Unterschied zwischen Recorder-Datei und Testressource wird gleich nach dieser Aufzählung erklärt.
Recorder: Welcher Aufnahmedienst soll verwendet werden?
Test-Generator: Welcher Test-Generator soll verwendet werden um eine TPTP-Testressource zu erstellen?

Der Recorder speichert die gesamte Kommunikation zwischen Browser und Web-Server(n) in einer Recording-Datei. Eine Recorder-Datei enthält alle aufgenommenen Nachrichten, und aus ihr kann die Testressource generiert werden. Nach der Testaufnahme stehen also zwei Dateien zur Verfügung: die Recorder-Datei mit allen Nachrichten in einem speziellen Trace-Datenschema [35], das in TPTP Standard ist für jegliche Test- und Messdatenaufzeichnung, und die daraus abgeleitete Testressource. Der Test-Generator ist für die Generierung der Testressource aus der Recorder-Datei verantwortlich.

Für diesen Anwendungsfall müssen, wie in Abbildung 3.11 dargestellt, folgende Einstellungen gewählt werden:

Testaufnahme = „Create Test From New Recording“.
Recorder = „URL Recorder“.
Test Generator = „TPTP Web TEST Generator“

Der von Web-TEST angebotene „TPTP Web TEST Generator“ hat den Vorteil, dass er auch die Antworten der Web-Servers, also die HTTP-Responses (im Folgenden kurz als Response bezeichnet), behandelt und sie in die erstellte Testressource einbaut. Der „TPTP URL Test Generator“ zeichnet hingegen keine Responses auf.

Abbildung 3.12: Der Testaufzeichnungs-Wizard zweite Seite

Als nächstes wird man nach einem Speicherort und einem Namen für die Testressource gefragt. Abbildung 3.12 stellt diesen Dialog dar. Nachdem man beides ausgewählt hat, kann man mit dem Button „Finish“ den Wizard beenden und die Testaufzeichnung wird gestartet. Dabei wird der zuvor eingestellte Browser automatisch gestartet. Dieser darf jedoch vorher noch nicht ausgeführt werden. Nun kann der Test in der SUT durchgespielt werden. Abbildung 3.13 veranschaulicht die Testaufzeichnung für dieses Szenario. Der Benutzer verwendet dabei die SUT wie üblich, während der Recorder im Hintergrund alle Anfragen (Requests) und Antworten (Responses) aufzeichnet.

Abbildung 3.13: Verwendung der SUT während der Testaufzeichnung

Für dieses Szenario wurde die Anwendung UnRisk-FACTORY in der Version 1.2.12 (siehe [2]) verwendet. Die im nächsten Teil dieses Kapitels verwendete Aufnahme kann wie folgt nachgestellt werden:

Aufruf der Seite http://www.unrisk.com/unriskfactory/pages/admin/overview.do im Browser
Login mit Benutzername „oeller“ und Passwort „oeller“.
Klicken des Links „Instruments“ im horizontalen Menu oben.
Klicken des Links „IR Types/Average Rate Floaters“ im vertikalen Menu links.
Danach erscheint eine Tabelle im zentralen Bereich. In der Zeile, in der die Spalte „Name“ den Wert „Test WebTEST1“ enthält, muss rechts auf den „Details“-Link geklickt werden.
Dann wird eine zweispaltige Tabelle angezeigt, die alle Eigenschaften des ausgewählten Objekts darstellt.
Klicken des Links „Edit“ rechts oberhalb der Tabelle.
Nun erscheint wieder eine Tabelle, die es erlaubt, die Eigenschaften des Objekts zu ändern.
Ändern des Felds ISIN auf „Test WebTEST_1“ anstelle von „Test WebTEST1“.
Die Änderungen durch betätigen des Buttons „Save Changes“ bestätigen.
Jetzt erscheint wieder die erste Tabelle, und man muss wieder auf den „Details“-Link in der Zeile „Test WebTEST1“ klicken.
Daraufhin erscheinen wieder alle Eigenschaften des Objekts. Die Eigenschaft „ISIN“ muss den neuen Wert „Test WebTEST_1“ haben.
Zuletzt noch über den Link „Logout“, äußerst rechts oben, ausloggen.

Sobald man fertig ist mit dem Durchspielen des Tests, kann man den Browser schließen. TPTP erkennt dann je nach Browser entweder automatisch, dass der Test beendet wurde, oder man muss noch den Stopp-Button () der Recorder-Ansicht betätigen. Danach wird der gewählte Test-Generator gestartet. Dieser generiert, aus den vom Proxy-Dienst aufgenommen Daten, die Testressource und öffnet den Web-TEST Assertion-Editor, wie in Abbildung 3.14 dargestellten.

Web-TEST-Editor-Actions

Abbildung 3.14: Der Assertion-Editor

In Abbildung 3.14 ist durch die leere Tabelle im linken unteren Teil der Editor-Seite erkennbar, dass für die erstellte Testressource noch keine Assertions generiert wurden. Der Assertion-Editor ist ein Multi-Page-Editor und bietet weitere Seiten an, um Assertions zu erstellen und zu bearbeiten. Zusätzlich zu den Funktionen zum Bearbeiten von Assertions, die im Kapitel 3.3.4 näher behandelt werden, bietet der Assertion-Editor folgende drei Editor-Actions (Buttons die in Eclipse speziell für einen Editor-Typ oberhalb des Editor-Fenster angezeigt werden – siehe auch Abbildung 3.14) an:

Change-Web-TEST-Editor (): Diese Aktion erlaubt es zwischen dem Web-TEST-Test-Editor zum Verwalten der Testdefinition und dem Web-TEST-Assertion-Editor zum Verwalten der Assertions zu wechseln.
Generate-JUnit-Code (): Mit Hilfe dieses Buttons kann aus der aktuellen Testressource Java-Code generiert werden. Der Java-Code ist später zum Ausführen des Tests erforderlich. In Web-TEST Version 1.0 wird aus jeder Testressource eine eigene Java-Klasse erzeugt, weil dies dem Standardschema in TPTP entspricht. Für eine spätere Version von Web-TEST ist geplant, dieses Java-Code-Klasse-pro-Testressource-Verfahren durch eine Ausführungsmaschine zu ersetzten, die die Testdefinition direkt interpretiert, ohne vorher Code erzeugen zu müssen.
BA-Assertion-Generation-Wizard (): Die Abkürzung BA steht für Business Attribute, und wird in der Oberfläche von Web-TEST verwendet, um zu lange Labelnamen zu vermeiden. Um diese Arbeit möglichst konsistent mit der Oberfläche von Web-TEST zu halten, wird auch hier diese Abkürzung verwendet. Die Aktion „BA-Assertion-Generation-Wizard“ startet einen Wizard, der eine automatische Generierung von Assertions anhand vordefinierter Templates und den aufgenommenen Responses erlaubt. Eine detaillierte Erklärung des Wizards erfolgt im Rahmen des Kapitels 3.3.3 „Erstellen von Assertions“.

Diese Aktionen stehen im Werkzeugmenu rechts oberhalb des Assertion-Editors als Buttons zur Verfügung (siehe Abbildung 3.14). Die Buttons sind nur aktiv, falls ein Web-TEST-Editor den Fokus besitzt.

3.3.2 Bearbeiten des aufgezeichneten Tests

Mit Hilfe der Change-Web-TEST-Editor-Aktion des Assertion-Editors kann auf den Test-Editor gewechselt werden. Dort kann man sich die vom Recorder erstellte Testressource ansehen und sie bearbeiten.

Testressource-Übersicht und Java-Code-Verzeichnis bearbeiten

Abbildung 3.15: Die Overview-Seite des Test-Editors

Man wird dabei auf die „Overview“-Seite des Test-Editors geleitet. Hier sieht man einen Überblick der aufgenommenen Requests. Abbildung 3.15 zeigt, dass neun Requests trotz Inhaltsfilter in die Testressource übernommen wurden. Diese Requests sind rechts unter der Überschrift „HTTP Requests“ zu sehen. Die Namen der Requests werden aus einer fortlaufenden Nummer, der Art des Requests (GET oder POST) und dem Titel der darin enthaltenen HTML-Seite zusammengesetzt. Weiters bietet die „Overview“-Seite die Möglichkeit festzulegen wo der später zu generierende Java-Quellcode gespeichert wird. Dazu kann man unter „Source Folder“ den Quellcodeordner des Java-Projekts, unter „Package Name“ den Paket-Namen und unter „Class Name“ den Klassennamen angeben. In diesem Szenario werden, wie in Abbildung 3.15 dargestellt, die Werte „Demo_WebTEST/src“, „org.eclipse.tptp.web.test.demo“ und „Demo_WebTEST“ verwendet. Um gegebenenfalls den Java-Code zu generieren, wird im Test-Editor die Generate-JUnit-Code-Aktion () angeboten. Das Erstellen des Java-Codes wird in diesem Anwendungsfall erst durchgeführt, nachdem alle nötigen Änderungen in der Testressource gemacht wurden. Beschrieben wird das Erzeugen des Java-Codes deshalb im Kapitel 3.3.6 „Abspielen des Tests und Kontrolle der Ergebnisse“.

Bearbeiten der Requests

Abbildung 3.16: Test-Editor-HTTP-Requests-Seite

Die zweite Seite des Test-Editors, die „HTTP Requests“-Seite, bietet die Übersicht und Detailansicht aller aufgenommenen Requests. Abbildung 3.16 zeigt links oben nochmals die neun aufgenommen Request. Diese können hier gelöscht, umgereiht oder neue hinzugefügt werden. Die Details des markierten und damit aktiven Requests, hier der Request „2 POST Admin Overview“, werden links unten unter „General Information“ und rechts unter „Detailled Porperties“ dargestellt. Dabei folgende Eigenschaften des aktiven Requests angezeigt und können editiert werden:

Name (Name)
Beschreibung (Description)
HTTP-Protokoll-Version (HTTP Version) – Diese Eigenschaft kann nicht geändert werden.
Host-Name (Host Name)
Port (Port)
Wartezeit (Think Time)
Absoluter Pfad (Absolute Path)
Verwendung von Secure-Socket-Layer (Uses SSL) – Wird von Web-TEST noch nicht interpretiert.
Die Request-Header (Headers)
Die Request-Parameter (Request Parameters)

Festlegen der Ausführungsreihenfolge der Requests

Wichtig ist hier anzumerken, dass die Reihenfolge der definierten Requests noch keine Auswirkung auf die Reihenfolge während der Testausführung hat. Die Ausführungsreihenfolge wird auf der Seite „Behavior“ des Test-Editors festgelegt (siehe Abbildung 3.17).

Abbildung 3.17: Test-Editor-Behavior-Seite

Als Standardreihenfolge wird die gleiche Reihenfolge verwendet, die auch aufgezeichnet wurde. In Abbildung 3.17 wird die Standardreihenfolge für diesen Anwendungsfall dargestellt. Es ist mit Hilfe der „Behavior“-Seite möglich, Requests umzureihen, Requests mehrmals zu verwenden oder gar nicht. Weiters können über den Button „Insert…“ Schleifen (Loops) definiert werden, um einen oder mehrere Requests vielfach auszuführen. Eine Schleife ist dabei ein spezieller Knoten im Baum der selber wieder Kinder haben darf.

Bearbeiten eines Responses

Die nächste Seite „Ref. Response Overview“ zeigt den Response des aktiven Request. Der aktive Request ist der Request der auf der Seite „HTTP Requests“ ausgewählt ist. Es gibt jedoch unter dem Punkt „Test Case Navigation“, die Möglichkeit die Auswahl des aktiven Requests zu ändern. In Abbildung 3.18 ist die „Ref. Response Overview“-Seite dargestellt und der Punkt „Test Case Navigation“ findet sich links oben. Auch in den Seiten „HTML Browser“, „DOM Browser“ und „BA Browser“ des Test-Editors findet man die „Test Case Navigation“-Komponente. Jede dieser Seiten des Test-Editors stellt den aktiven Response auf eine spezielle Weise dar.

Abbildung 3.18: Test-Editor-Ref.-Response-Overview-Seite

Die „Ref. Response Overview“-Seite erlaubt es weiters, die Eigenschaften eines Responses zu betrachten, zu ändern und den Inhalt des aktiven Responses über die Aktion „Replace response body from file...“ zu ersetzten. Die angezeigten Eigenschaften des Responses sind:

Protokoll (Protocol)
Protokoll Version (Protocol Version)
Status Code (Return Code)
Status Nachricht (Return Message)
Typ des Inhalts (Content Type)
Länge des Inhalts (Content Length)
Decodierter Ausschnitt aus dem Inhalt (Body)
Response-Header (Headers)

Weiters wird links unter der Überschrift „Associated Assertions“ eine Übersicht von Assertions angezeigt. Diese Assertions beziehen sich auf den dargestellten Response. Zurzeit wurde noch keine Assertion für diesen Response erstellt, deshalb wird in Abbildung 3.18 noch kein Eintrag angezeigt.

3.3.3 Erstellen von Assertions

Assertions lassen sich auf benutzerfreundliche Weise mit Hilfe der übrigen Seiten des Test-Editors erzeugen. Bevor dieser Anwendungsfall sich mit dem Erstellen von Assertions beschäftigt, muss zuerst der Aufbau einer Assertion erklärt werden. Eine Assertion ist ein Container, der Kriterien enthält. Die Kriterien enthalten wiederum Basiskriterien. Abbildung 3.19 zeigt den Aufbau von Assertions und verwendet dazu die in der Web-TEST-Oberfläche verwendete Benennung der Elemente.

Abbildung 3.19: Der hierarchische Aufbau von Assertions

Basiskriterium (Basic Criterion)

Das Basiskriterium ist die kleinste Einheit und wird durch einen Namen, einem Wert und einem Vergleichsoperator definiert. Ein Basiskriterium enthält im Wesentlichen den Wert nach dem gesucht wird. Je nach Typ des einschließenden Kriteriums wird dieser Wert in einem anderen Teil des Responses gesucht. Beispiel für ein Basiskriterium: Name=“HTML-Seiten-Titel“, Wert=“Administration“ und Vergleichoperator=“Equals“.

Kriterium (Criterion)

Ein Kriterium ist eine Zusammenstellung von ein oder mehreren Basiskriterien und zusätzlichen Eigenschaften. Die zusätzlichen Eigenschaften gelten für alle enthaltenen Basiskriterien. Kein Basiskriterium eines Kriteriums darf fehlschlagen, damit das Kriterium erfüllt ist.

Mit Hilfe von verschiedenen Kriterientypen ist es möglich einen Response auf verschiedene Arten zu untersuchen. In der aktuellen Version von Web-TEST werden drei Arten von Kriterien unterstütz:

Text-Kriterium (Text-Criterion): Überprüft das Vorkommen eines oder mehrerer Texte in der gesamten HTML-Seite. Beispielsweise kann man so überprüfen, ob ein bestimmter Text wie „Error“ irgendwo in der HTML-Seite vorkommt.
XPath-Kriterium (XPath-Criterion): Überprüft den Wert eines XPath-Ausdrucks. Mit dieser Art von Kriterium kann man beispielsweise überprüfen, ob der Titel eine HTML-Seite einen bestimmten Wert hat.
BA-Kriterium (Business-Attribute-Criterion): Testet die Werte von Elementen, die zu einem bestimmten Musters passen. Mit diesem Kriterium kann man beispielsweise alle angezeigten Eigenschaften eines Geschäftsfeld-Objekts (Business-Objekts) der SUT, wie sie etwa in Abbildung 1.2 für UnRisk FACTORY dargestellt sind, überprüfen.

Die Details der einzelnen Kriterientypen werden im Kapitel 3.3.4 „Bearbeiten der Assertions“ erklärt.

Assertion

Eine Assertion ist die Beschreibung, wann welche Kriterien überprüft werden müssen. Dazu können einer Assertion, wie in Abbildung 3.19 dargestellt, eine Menge von Kriterien zugeteilt werden und außerdem können zu testende Funktionen, also Requests, zugeteilt. Falls nun ein zugeteilter Request während einer Testausführung abgespielt wird, dann wird die Assertion aktiviert und alle darin enthaltenen Kriterien werden mit dem folgendem Response verglichen. Eine Assertion kann aus 0 bis n Kriterien und 0 bis n zugeteilten Requests bestehen, wobei n theoretisch unbegrenzt ist. Wenn eine Assertion ausschließlich Kriterien eines Kriterientyps enthält, dann wird diese Assertion im Folgenden nach diesem Typ benannt. Als Beispiel: eine Assertion die nur Text-Kriterien enthält, wird auch als Text-Assertion bezeichnet.

Erstellen von Text-Assertions

Um eine Text-Assertion erstellen zu können, wechselt man auf die Seite „HTML Browser“ des Test-Editors. Hier wird der aktive Response in einem HTML-Browser dargestellt. Da der Browser nicht mit der SUT verbunden ist, sondern auf einer lokalen Kopie des Responses arbeitet, können Bilder- und Stylesheet-Dateien nicht geladen werden.

Web-TEST-Editor-Actions

Abbildung 3.20: Die HTML-Browser-Seite des Test-Editors

Wie in Abbildung 3.20 dargestellt, kann Text direkt im Browser markiert werden. Der markierte Text kann dann verwendet werden, um für den aktiven Request eine Assertion zu erstellen. Dazu bietet der Test-Editor die Aktion Create-Assertion (). Abbildung 3.20 zeigt diese Aktion direkt neben der Generate-JUnit-Code-Aktion () rechts oberhalb des Test-Editors an.

Abbildung 3.21: Der Automatic-Assertion-Generation-Dialog für eine Text-Assertion

Nach betätigen der Create-Assertion-Aktion () erscheint ein Informationsdialog, wie er in Abbildung 3.10 dargestellt ist. Dieser Dialog zeigt noch einmal die Eigenschaften der zu erstellenden Assertion. Dabei werden folgende Informationen geliefert:

Art des verwendeten Kriteriums: „Text“
Wert der Bedingung in einfachen Anführungszeichen: „Administration“
Name der neuen Assertion: „Browser View Assertion 0“

In diesem Beispiel wird also ein Text-Kriterium mit genau einem Basiskriterium erzeugt. Das Basiskriterium wird auf den Wert „Administration“ gesetzt. Das Text-Kriterium wird einer neuen Assertion mit dem Namen „Browser View Assertion 0“ zugeteilt. Weiters wird der aktive Request mit dieser Assertion verknüpft. Abbildung 3.22 zeigt nochmals grafisch den Aufbau der Assertion „Browser View Assertion 0“.

Abbildung 3.22: Aufbau der Assertion "Browser View Assertion 0"

Diese Assertion sucht bei der Testausführung in der HTML-Seite des Responses (des Requests) „2 POST Admin Overview“ den Text „Administration“. Wird dieser Text irgendwo in der HTML-Seite gefunden, dann ist die Assertion erfolgreich.

Um diese Assertion automatisch erstellen zu lassen, muss man nur den angezeigten Dialog bestätigt. Wenn man anschließend wieder auf die Seite „Ref. Response Overview“ zurück geht, erkennt man das in der Tabelle „Associated Assertions“ die Assertion „Browser View Assertion 0“ eingetragen ist.

Erstellen von XPath-Assertions

Um eine Assertion für den Wert eines bestimmten XPath-Ausdrucks zu erstellen, wechselt man auf die Seite „DOM Browser“. Hier kann man Assertion erstellen die beispielsweise überprüfen, ob ein bestimmte Überschrift in einer HTML-Seite einen bestimmten Wert hat.

Abbildung 3.23: Die DOM-Browser-Seite des Test-Editors

In Abbildung 3.23 wurde mittels Auswahl aus dem DOM-Baum ein bestimmtes Element ausgewählt und der XPath-Ausdruck automatisch dafür generiert. Es ist genauso möglich einen XPath-Ausdruck anzugeben und daraus die Selektion im Baum zu generieren. Auf der rechten Seite wird dann in einem Browser und zusätzlich in einem Textfeld das Ergebnis der Ausführung des XPath-Ausdrucks im Response angezeigt. Auch für XPath-Assertions steht wieder die Create-Assertion-Aktion () zur Verfügung.

Abbildung 3.24: Der Automatic-Assertion-Generation-Dialog für eine XPath-Assertion

Wie Abbildung 3.24 darstellt, erstellt diese Aktion, wenn sie aus der „DOM Browser“-Seite aufgerufen wird, eine XPath-Assertion. Diese Assertion überprüft bei der Ausführung, ob im Response der XPath-Ausdruck „/html[1]/body[1]/div[5]/h1[1]“ ausgewertet werden kann und dabei der Wert „\r\n\tAdministartion\r\n\t“ geliefert wird. Wie man erkennen kann, sind mit Hilfe dieses Kriterientyps bereits deutlich restriktivere Bedingungen möglich. Erstens muss das Element „/html[1]/body[1]/div[5]/h1[1]“ im DOM-Baum existieren und zweitens muss genau dieses Element den gesuchten Wert enthalten.

Wenn man nun den in Abbildung 3.24 dargestellten Dialog bestätigt und dann wieder auf die Seite „Ref. Response Overview“ wechselt, sieht man das jetzt zwei Assertions dem aktiven Request zugeordnet sind.

Erstellen von BA-Assertions

Die dritte Art von Kriterien dient dazu, zu testen, ob eine Anzahl von Attributen beziehungsweise Elementen mit richtigem Namen und Wert auf einer HTML-Seite vorkommen. Beim Erstellen eines BA-Kriteriums wird versucht, aus der HTML-Seite eines aufgezeichneten Responses eine Liste von Elementen zu extrahieren. Ein Element kann dabei alles sein, das einen Namen und einen Wert besitzt und Name und Wert mittels eines bestimmten Muster gefunden werden. BA-Kriterien verwenden zum Extrahieren der Elemente, ihrer Namen und ihrer Werte aus dem Response XPath-Ausdrücke. Im Gegensatz zum XPath-Kriterium werden allerdings für ein BA-Kriterium drei XPath-Ausdrücke benötigt.

Der XPath-Ausdruck für das Element (Get Element): Dieser Ausdruck wählt aus dem Response alle zu betrachtenden Elemente aus. Wie schon zuvor erwähnt wird das Element noch in einen Namen und einem Wert zerlegt. Wobei der Wert auch leer sein darf.
Der XPath-Ausdruck für den Namen (Extract Name): Dieser Ausdruck wird auf jedes gefunden Element angewendet um den Namen zu extrahieren.
Der XPath-Ausdruck für den Wert (Extract Value): Dieser Ausdruck liefert den Wert des Elements.

Die Kombination aus diesen drei Ausdrücken wird als BA-Muster (BA-Expression) bezeichnet. Die Elemente, die mit Hilfe eines BA-Musters gefunden werden, werden als Business-Attribute-Instances (BAIs) bezeichnet. Abbildung 3.25 zeigt die “BA Browser”-Seite. Auf dieser Seite wurde der aktive Response („5 Get Average Rate Floater Details“) bereits mit dem in der Abbildung dargestellten BA-Muster analysiert. Deshalb sind in der Tabelle auf der rechten oberen Hälfte unter der Überschrift „BA Expression Results“ bereits BAIs dargestellt. In der Tabelle der oberen Hälfte werden Namen und Werte der BAIs als Text dargestellt. Da diese jedoch wieder HTML-Elemente enthalten können, werden in einem HTML-Browser-Feld darunter alle Elemente nochmals dargestellt, wie sie in einem Web-Browser angezeigt werden.

Abbildung 3.25: Die BA-Browser-Seite des Test-Editors nach Auswahl des Templates „UnRisk Detail Table Template“

Um den in Abbildung 3.25 dargestellten Zustand herzustellen, müssen folgende drei Schritte durchgeführt werden:

Mit Hilfe der „Test Case Navigation“, muss der aktive Request auf „5 GET Average Rate Floater Details“ gesetzt werden.
Danach muss in der Combo-Box „Use Template“ das BA-Template „UnRisk Detail Table Template“ ausgewählt werden. Dabei werden die XPath-Ausdrücke für Element, Name und Wert ausgefüllt. Ein BA-Template ist ein vordefiniertes BA-Muster mit einem Namen.
Schließlich kann der Button „Extract from Response“ verwendet werden, um die Elemente beziehungsweise die BAIs des aktiven Responses zu extrahieren. Dabei werden die BAIs in eine Tabelle und in einem HTML-Browser auf der rechten Hälfte der Test-Editor-Seite eingetragen.

Nun ist es möglich, eine BA-Assertion generieren zu lassen, die das eingestellte BA-Muster und die im aufgenommen Response gefunden BAIs verwendet. Dazu steht wieder die Create-Assertion-Aktion () zur Verfügung.

Abbildung 3.26: Der Automatic-Assertion-Generation-Dialog für eine BA-Assertion

Wie Abbildung 3.26 darstellt, wird mit dieser Aktion in diesem Kontext eine BA-Assertion erstellt. Diese Assertion überprüft bei der Ausführung, ob im Response das BA-Muster ausgewertet werden kann und alle Elemente mit den richtigen Werten in der korrekten Reihenfolge gefunden werden. Bei der Testausführung müssen also alle Werte, wie sie in der BAI-Tabelle von Abbildung 3.25 dargestellt sind, gefunden werden. Zum Erstellen der BA-Assertion wird aus jedem BAI der BAI-Tabelle von Abbildung 3.25 ein Basiskriterium erstellt und mit dem BA-Kriterium der Assertion verknüpft. Das BA-Kriterium enthält das zu prüfenden BA-Muster. Diese BA-Assertion wird nun automatisch durch bestätigen des Dialogs in Abbildung 3.26 erstellt. Eine detaillierte Erläuterung des BA-Kriteriums folgt in Kapitel 3.3.4 „Bearbeiten der Assertions“. Dort wird unter anderem auch gezeigt, wie man unerwünschte BAIs wieder aus dem Kriterium entfernt.

BA-Templates

Im Laufe der Verwendung des BA-Musters in Web-TEST wurde eine wichtige Entdeckung gemacht: Man benötigt nur eine kleine Menge von verschiedenen BA-Mustern, um nahezu alle Responses einer speziellen SUT analysieren zu können. Folgende Eigenschaften von HTML-basierten Webanwendungen können dafür verantwortlich gemacht werden:

HTML verwendet standardisierte Elemente zur Darstellung und Eingabe von Werten wie etwa Input- und Select-Felder. Informationen werden etwa oft in zweispaltigen Tabellen im zentralen Bereich der Ansicht dargestellt. Wobei die erste Spalte meist den Titel und die zweite Spalte den Inhalt der Information darstellt. Auch UnRisk-FACTORY verwendet dieses Schema wie in der Einleitung schon gezeigt.
Webanwendungen verwenden meist für alle HTML-Seiten ein einheitliches Schema. Die Struktur der Informationen auf den verschiedenen HTML-Seiten ist also identisch.

Durch Eigenschaft 1 ist es möglich allgemeine BA-Muster zu definieren und diese für alle Responses, in denen beispielsweise Input-Felder vorkommen, zu verwenden. Das BA-Muster für Input-Felder sieht immer gleich aus und kann deshalb als BA-Template in Web-TEST vordefiniert werden. Weiters ermöglicht Punkt 2, dass ein BA-Muster für viele HTML-Seiten einer bestimmten SUT verwendet werden kann. Web-TEST ermöglicht es deshalb, zusätzliche BA-Templates zu definieren. Dadurch erspart man sich die Eingabe der drei XPath-Ausdrücke beim Eingeben eines BA-Musters. Im Beispiel von Abbildung 3.25 wurde bereits eines dieser vordefinierten Templates („UnRisk Detail Table Template“), das speziell auf die Informationsdarstellung von UnRisk-FACTORY eingestellt wurde, verwendet.

Abbildung 3.27: Konfiguration von BA-Templates

Abbildung 3.27 zeigt die drei von Web-TEST Version 1.0 standardmäßig vordefinierten BA-Templates. Zu finden ist die Eclipse-Einstellungsseite zum Verwalten der BA-Templates unter dem Menu „Window/Preferences …“ und dem Pfad „Test/Web-TEST/Business Attribute Criterion“. Hier können die BA-Templates geändert, erstellt oder gelöscht werden. Zusätzlich zu dem BA-Muster kann man auch noch einen Namen, eine Beschreibung sowie Skip-Names (Skip-Attribute-Names) angeben. Skip-Names sind Namen von Elementen die ignoriert werden sollen. Diese Skip-Names werden ausschließlich im BA-Assertion-Generation-Wizard () verwendet.

Der BA-Assertion-Generation-Wizard

Der BA-Assertion-Generation-Wizard wird über die gleichnamige Aktion aufgerufen. Die Aktion steht sowohl im Assertion- wie auch im Test-Editor zur Verfügung.

Abbildung 3.28: Der BA-Assertion-Generation-Wizard

Abbildung 3.28 zeigt den BA-Assertion-Generation-Wizard. Der Wizard kann zur automatischen Generierung einer Menge von BA-Assertions verwendet werden. Auf der linken Seite werden alle Requests in einer Tabelle angezeigt. Auf der rechten Seite werden alle vordefinierten BA-Templates und die zugeordneten Requests in einem Baum angezeigt.

Die Requests können mit dem „Add Selected >>“-Button zum aktuellen BA-Template im Baum zugeordnet werden. Das aktuelle Template wird dabei in der Mitte des Wizards oben unter der Bezeichnung „Actual Template:“ angezeigt und kann durch Auswahl eines anderen Knotens im Baum geändert werden.

Weiters kann über den Button „Add All Matching >>“ ein Dienst aufgerufen werden, der alle sinnvollen Kombinationen von Requests und BA-Templates in den Baum rechts einträgt. Dabei wird jedes BA-Template in jedem aufgenommenen Response ausgeführt. Wenn zumindest ein Element im Response gefunden wird, dessen Name nicht in den Skip-Namen des BA-Templates enthalten ist, dann wird der zugehörige Request zu dem verwendeten BA-Template im Baum eingetragen. In Abbildung 3.28 wurde dieser Button bereits benützt und alle sinnvollen BA-Assertions werden vorgeschlagen. Hinweis: Da für den Request „5 GET Average Rate Floater Details“ bereits manuell eine BA-Assertion erstellt wurde, ist es sinnvoll, diesen Request mittels „<< Remove Selected“-Button wieder aus dem Baum zu entfernen.

Darauf hin kann mit „Finish“ der Vorschlag bestätigt und der Wizard beendet werden. Dabei erscheint eine Meldung, dass die Testressource im Dateisystem geändert wurde. Diese Meldung muss mit „Yes“ bestätigt werden, damit alle Änderungen in der Testressource gespeichert werden. Schließlich wird man auf die „Behavior“-Seite des Test-Editors geleitet.

3.3.4 Bearbeiten der Assertions

Nachdem man mit Hilfe des Test-Editors die nötigen Assertions angelegt hat, kann man im Assertion-Editor die Assertions überprüfen und sie noch anpassen. Dazu verwendet man wieder die Aktion Change-Web-TEST-Editor (), um diesmal vom Test-Editor auf den Assertion-Editor zu wechseln. Dabei wird man auf die, in Abbildung 3.29 dargestellte, „Assertion Overview“-Seite des Assertion-Editors geleitet.

Die Übersicht der Assertions in der Testressource

Abbildung 3.29: Die Assertion-Overview-Seite des Assertion-Editors

Man sieht nun alle erzeugten Assertions in einer Tabelle links unten in der „Assertion Overview“-Seite. Abbildung 3.29 zeigt, dass in diesem Szenario fünf Assertions angelegt wurden. Von den Namen der Assertions kann abgeleitet werden, aus welcher Seite des Test-Editors diese erstellt wurden. Eine Assertion wurde von der „HTML Browser“-Seite, eine von der „DOM Browser“-Seite, eine von der „BA Browser“-Seite aus erstellt. Die beiden übrigen Assertions wurden durch den BA-Assertion-Generation-Wizard angelegt. Diese werden mit dem Namen „Auto Assertion“ und einer laufenden Nummer gekennzeichnet.

Man kann nun die Details der einzelnen Assertions auf der rechten Seite betrachten und editieren. In Abbildung 3.29 ist die Assertion „Browser View Assertion 0“ ausgewählt und man sieht, dass sie aus einem Text-Kriterium („Browser View Text Criterion 0“) besteht und dass diese Assertion dem Request „2 POST Admin Overview“ zugeteilt wurde.

Bearbeiten von Text-Kriterien

Auf der Seite „Text Criterion“ kann man das verwendete Text-Kriterium weiter bearbeiten. Abbildung 3.30 zeigt diese Seite mit den Details des Kriteriums „Browser View Text Criterion 0“.

Abbildung 3.30 Die Text-Criterion-Seite des Assertion-Editors

Auf dieser Seite können Text-Kriterien erstellt, gelöscht und bearbeitet werden. Ein Text-Kriterium hat einen Namen, eine Beschreibung und eine Menge von Basiskriterien. Weitere Basiskriterien können hinzugefügt, entfernt und editiert werden. Für Basiskriterien von Text-Kriterien kann man folgende Eigenschaften festlegen:

Name (Name)
Beschreibung (Description)
Wert (Search Text)
Werden reguläre Ausdrücke im Wert verwendet (Use RegEx)
Soll nur der Textinhalt eines Responses ohne den HTML-Tags und -Attributen überprüft werden (Use Only Response Text (ignore HTML))
Vergleichsoperation: der Wert muss enthalten sein oder der Wert darf nicht enthalten sein (Match Rule: Must Contain vs. Must not Contain)

Bearbeiten von XPath-Kriterien

Auch die XPath-Kriterien können auf ähnliche Weise gewartet werden. Hierfür steht die Seite „XPath Criterion“, wie in Abbildung 3.31 gezeigt, zur Verfügung.

Abbildung 3.31: Die XPath-Criterion-Seite des Assertion-Editors

Auf dieser Seite können XPath-Kriterien erstellt, gelöscht und bearbeitet werden. Ein XPath-Kriterium hat einen Namen, eine Beschreibung, einen XPath-Ausdruck (XPath-Expression) und eine Menge von Basiskriterien. Auch hier können Basiskriterien hinzugefügt, entfernt und editiert werden. Für Basiskriterien von XPath-Kriterien kann man folgende Eigenschaften festlegen:

Name (Name)
Beschreibung (Description)
Wert (Compare Value)
Datentyp (Compare Data Type)
Vergleichsoperator (Compare Operator)
Werden reguläre Ausdrücke im Wert verwendet (Use RegEx (Only possible if data type is String))

Als Datentyp stehen „String“, „Integer“ oder „Double“ zur Verfügung. Weiters werden folgende Vergleichsoperatoren unterstützt: „Equals“, „Not Equal“, „Less Than“, „Greater Than“, „Contains“ und „Doesn’t Contain“.

Bearbeiten von BA-Kriterien

Schließlich können auch BA-Kriterien auf der Seite „Business Att. Criterion“ bearbeitet werden. Abbildung 3.32 zeigt diese Seite mit den BA-Kriterien, die im Rahmen des Anwendungsfalls bereits erstellten wurden.

Abbildung 3.32: Die BA-Criterion-Seite des Assertion-Editors

Mit Hilfe der linken Hälfte der Seite können BA-Kriterien erstellt, gelöscht und bearbeitet werden. Ein BA-Kriterium hat einen Namen, eine Beschreibung, ein BA-Muster, einen Schalter „Test Business Attribute Sequence“ und eine Menge von Basiskriterien, die in diesem Rahmen wieder als „Business Attribute Instances“ (BAIs) bezeichnet werden. Der Schalter „Test Business Attribute Sequence“ garantiert, dass bei der Testausführung die BAIs in der gleichen Reihenfolge gefunden werden, wie sie im BA-Kriterium definiert sind. Wieder können Basiskriterien hinzugefügt, entfernt und editiert werden.

Weiters gibt es auch über den Punkt „Business Attribute Auto Generation“ die Möglichkeit, automatisch zusätzlich Basiskriterien zu einem BA-Kriterium hinzuzufügen. Ähnlich wie in der Abbildung 3.25, die die BA-Browser-Seite des Test-Editors beschreibt, kann man auch hier wieder ein BA-Template und einen Request wählen. Man kann aus diesem Request alle Elemente extrahieren, die dem angegebenen BA-Muster entsprechen. Für die Basiskriterien (die BAIs) von BA-Kriterien gelten die gleichen Eigenschaften wie für die Basiskriterien von XPath-Kriterien, mit der Ausnahme, dass keine Beschreibung eingegeben werden kann. Üblicherweise sind hier nach der automatischen Generierung über den Punkt „Business Attribute Auto Generation“, über die „BA Browser“-Seite des Test-Editors oder über den BA-Assertion-Generation-Wizard kaum mehr Änderungen nötig da beispielsweise auch der Vergleichoperator mit dem Standardwert „Equals“ vorbelegt wird.

Abbildung 3.32 zeigt auch, dass in dem Szenario vier BA-Kriterien erzeugt wurden. Wobei am Namen der Kriterien erkennbar ist, dass drei der Szenarien vom BA-Assertion-Generation-Wizard (Name der Assertions fängt mit „Auto BA“ an) und eines aus der „BA Browser“-Seite („BA View Criterion 0“) erzeugt wurden.

Wenn man nun die Liste der BAIs des BA-Kriteriums „BA View Criterion 0“ betrachtet, dann findet man dort die beiden Einträge „Creation Date“ und „Modification Date“. Diese Elemente sind in den Skip-Namen des BA-Templates enthalten und sind deshalb in den durch den Wizard erzeugten BA-Kriterien nicht mehr enthalten. Die „BA Browser“-Seite ignoriert jedoch die Skip-Namen eines BA-Templates, weshalb diese BAIs in der „BA View Criterion 0“ noch enthalten sind. Normalerweise werden BA-Kriterien für die es schon ein BA-Template gibt mit dem BA-Assertion-Generation-Wizard erzeugt und die „BA Browser“-Seite wird lediglich zum Testen neuer BA-Templates verwendet.

Es ist sehr wahrscheinlich, dass sich das „Modification Date“ in der von dem BA-Kriterium „BA View Criterion 0“ getesteten HTML-Seite beim späteren Abspielen des Tests ändert. In diesem Fall bekommt man eine Meldung, dass dieses Kriterium nicht erfüllt wird. Im Regelfall werden deshalb die Attribute, die sich ändern dürfen, aus der Liste der BAIs entfernt. Dies kann mit dem „Remove“-Button neben der BAI-Tabelle erledigt werden.

In diesem Anwendungsfall soll auch gezeigt werden, was passiert, wenn eine Assertion nicht erfüllt wird. Deswegen wird hier die BAI mit dem Namen „Currency“ auf einen Wert gesetzt, der bei der Testausführung nicht gefunden werden kann. Dazu kann einfach die BAI „Currency“ aus der Tabelle ausgewählt werden und der „Compare Value“ von „EUR“ auf „USD“ umgestellt werden.

Abbildung 3.33: Ändern des Werts des Currency-BAIs auf "USD"

Abbildung 3.33 zeigt diese Änderung im BA-Kriteriums „BA View Criterion 0“. Beim Ausführen des Tests wird nochmals darauf hingewiesen, dass mit Absicht eine Assertion erzeugt wurde, die einen Fehler liefern muss. Es wird auch gezeigt, dass Web-TEST diesen Fehler richtig erkennt.

3.3.5 Festlegung von dynamischen Request-Parametern

Neben der Definition von Assertions können im Assertion-Editor auch dynamische Request-Parameter erstellt werden. Diese Parameter können beispielsweise eingesetzt werden, um lange Transaktionen zu unterstützen. Als lange Transaktionen bezeichnet man im Bereich von Webanwendungen Transaktionen, die mehrere Request benötigen. UnRisk-FACTORY verwendet lange Transaktionen etwa für das Editieren von Objekten. Dabei werden beim Erzeugen einer HTML-Seite, die zum Editieren eines Objekts dient, bereits alle Objekteigenschaften am Webserver gespeichert. Dem Benutzer wird dann die HTML-Seite mit einem zusätzlichen, versteckten Identifikationsfeld gesendet. Der Wert des Identifikationsfelds referenziert die am Webserver gespeicherten Objektdaten. Wenn der Benutzer von UnRisk-FACTORY seine Änderungen bestätigt, dann wird dieser Wert in den Bestätigungs-Request aufgenommen und an den Server gesandt. Der Server kann so auf die bereits gespeicherten Daten zugreifen und die neuen Änderungen eintragen. Das Problem beim Abspielen ist, dass der Wert des Identifikationsfelds am Webserver beim Aufnehmen nicht der gleiche ist wie beim Abspielen. Der Bestätigungs-Request kann also beim Abspielen nicht mehr den gespeicherten Wert des Identifikationsfeldes verwenden, sondern muss den neuen Wert des Webservers verwenden.

Web-TEST löst dieses Problem mittels dynamischer Request-Parameter. Dynamische Request-Parameter werden mit Hilfe eines Response-Value-Selectors aus einem Response gelesen und durch einen Request-Value-Selector in einem folgenden Request verwendet. Ein Response-Value-Selector definiert einen XPath-Ausdruck, der einen Wert aus dem Response extrahiert. Ein Request-Value-Selector definiert einen Request-Parameternamen, als dessen Wert der zuvor gefundene Wert verwendet werden soll. Abbildung 3.34 zeigt die Definition eines Response-Value-Selectors.

Abbildung 3.34: Die Value-Selector-Seite des Assertion-Editors

Um den in Abbildung 3.34 dargestellten Zustand nachzustellen, muss man mit dem Button „New…“ einen neuen Value-Selector anlegen. Dabei wird als Standardtyp „Response“ ausgewählt. Danach muss man einen XPath-Ausdruck festlegen. In diesem Beispiel muss „//input[@name='responseUID']/@value“ eingegeben werden. Als Referenz-Response (Reference-Response) muss „6 GET Modify Average Rate Floater“ ausgewählt werden. Mit Hilfe dieses Response-Value-Selectors wird im Response nach einem Input-Feld mit Namen „responseUID“ gesucht. Um den Response-Value-Selector in einem Referenz-Response zu testen, kann der „Refresh“-Button verwendet werden. Dabei wird der gefunden Wert links unten im Punkt „Test Value Selector“ angezeigt.

Um nun einen dynamischen Request-Parameter für das Feld „responseUID“ erzeugen zu können, muss noch ein Request-Value-Selector erstellt werden. Dazu klickt man wieder auf den „New …“-Button, wählt als Typ „Request“ aus und stellt als Referenz-Response „7 POST Show Average Rate Floaters“ ein. Schließlich wählt man als Request-Parameternamen (Request-Parameter) „responseUID“ aus.

UnRisk-FACTORY benötigt jedoch noch einen zweiten Parameter mit Namen „SUId“ um eine lange Transaktion durchführen zu können. Man kann hier nach dem gleichen Schema wie für „responseUID“ vorgehen, um Response- und Request-Value-Selector zu erzeugen.

Es gibt jedoch eine benutzerfreundlichere Alternative um den Response-Value-Selector zu erzeugen, wobei man sich die Eingabe des XPath-Ausdrucks erspart. In Abbildung 3.23, auf der „DOM-Browser“-Seite, sieht man eine zusätzliche Editor-Aktion: Generate-Response-Value-Selector (). Diese Aktion erlaubt es, direkt aus der „DOM Browser“-Seite einen Response-Value-Selector zu erstellen. Man geht dabei genauso vor, wie wenn man eine XPath-Assertion erstellen möchte. Abbildung 3.35 zeigt den Informationsdialog, den man beim Erstellen des Response-Value-Selectors für das Feld „SUId“ bekommt, wenn man die Generate-Response-Value-Selector-Aktion verwendet.

Abbildung 3.35: Der Automatic-Value-Selector-Generation-Dialog

Wie der Dialog zeigt, muss ein XPath-Ausdruck mit dem Wert „//input[@name='SUId']/@value“ verwendet werden, um den Response-Value-Selector zu erstellen. Außerdem muss der Request „6 GET Modify Average Rate Floater“ ausgewählt werden. Zuletzt muss noch im Assertion-Editor der Request-Value-Selector für das Feld „SUId“ angelegt werden, bevor die für UnRisk-FACTORY nötigen dynamischen Request-Parameter erstellt werden können. Abbildung 3.36 zeigt die Einstellungen dieses Request-Value-Selectors für das Feld „SUId“. Weiters zeigt diese Abbildung alle vier benötigten Value-Selectoren in der Tabelle links oben.

Abbildung 3.36: Die Value-Selector-Seite des Assertion-Editors mit den benötigen Value-Selectoren

Mit Hilfe dieser Value-Selectoren können nun dynamischen Request-Parameter für die Felder “responseUID” und “SUId” angelegt werden. Wie schon zuvor erwähnt, werden diese beiden Parameter von UnRisk-FACTORY benötigt, um lange Transaktionen bei der Testausführen abspielen zu können. Diese Parameter können jetzt auf der Seite „Parameter“ erstellt werden. Abbildung 3.37 zeigt die beiden Parameter, die für dieses Szenario definiert werden müssen.

Abbildung 3.37: Die Parameter-Seite des Assertion-Editors

Ein neuer Parameter wird mit Hilfe des Buttons „New …“ angelegt und seine Eigenschaften können dann editiert werden. Mit dem Button „Refresh“ kann überprüft werden, welche Werte aus den aufgezeichneten Referenz-Requests und -Responses der zugrundeliegenden Value-Selectoren gelesen beziehungsweise ersetzt werden. Die „Parameter“-Seite bietet folgende Felder an, um die Eigenschaften eines dynamischen Request-Parameters festzulegen:

Name (Name)
Standardwert (Default Value)
Response-Value-Selector (Response Value Selector)
Request-Value-Selector (Request Parameter Selector)
Die Responses, aus denen der Wert während der Testausführung gelesen wird (Parameter Value Aquired From Response of Tests)
Die Requests, in denen der Wert verwendet wird (Parameter Value Used in Requests)

Die in Abbildung 3.37 dargestellten Parameter müssen mit den in Tabelle 3‑1 dargestellten Werten befüllt werden.

Parameter Eigenschaft	Parameter 0 (für „responseUID”)	Parameter 1 (für „SUId”)
Response-Value-Selector	Value-Selector-0 (=Response-Value-Selector für „responseUID”)	DOM View Value Selector 0 (=Response-Value-Selector für „SUId”)
Request-Value-Selector	Value-Selector-1 (=Request-Value-Selector für „responseUID”)	Value-Selector-2 (=Request-Value-Selector für „SUId”)
Aquired from Responses	6 GET Modify Average Rate Floater	6 GET Modify Average Rate Floater
Used in Requests	7 POST Show Average Rate Floaters	7 POST Show Average Rate Floaters

Tabelle 3‑1: Die Werte der Request-Parameter für die Parameter „responseUID“ und „SUId“

3.3.6 Abspielen des Tests und Kontrolle der Ergebnisse

Das Test-Szenario ist jetzt vollständig definiert. Bevor man den Test jedoch abspielen kann, muss man noch den zur Testausführung benötigten Java-Code erzeugten. Wie schon zuvor erwähnt, wird in Web-TEST für jede Testressource eine eigene JUnit-Test-Klasse erzeugt, weil dies dem von TPTP vorgegebenen Schema entspricht.

Automatisches Erzeugen des Java-Code

Dazu kann die Generate-JUnit-Code-Aktion () verwendet werden, die bereits in Kapitel 3.3.1 „Aufzeichnen eines Tests“ vorgestellt wurde. Beim Aufruf dieser Aktion erscheint ein Dialog zum Einstellen des Quellcode-Verzeichnisses. Diese Einstellungen wurde schon im Kapitel 3.3.2 „Bearbeiten des aufgezeichneten Tests“ im Test-Editor vordefiniert. Deshalb kann der Dialog einfach bestätigt werden. Nun wird eine Java-Klasse mit dem Namen „Demo_WebTEST“ im Packet „org.eclipse.tptp.web.test.demo“ erzeugt. Diese Java-Klasse ist eine ausführbare Ableitung der Testressource.

Um zu kontrollieren, ob der Java-Code erzeugt wurde, kann man in die Eclipse-Perspektive „Java“ wechseln. Abbildung 3.38 zeigt wie das Projekt „Demo-WebTEST“ nun aussehen muss. In der Abbildung ist auch die Datei „Demo_WebTEST.java“ erkennbar, die den generierten Test-Quellcode enthält.

Abbildung 3.38: Die Package-Explorer-Ansicht des Projekts „Demo_WebTEST“.

Ausführen des Tests

Bevor man den Test nun ausführt, muss die SUT noch in den dafür nötigen Ausgangszustand gebracht werden. Normalerweise werden dazu Datenbank-Backups verwendet, um die Anwendung auf den Zustand vor der Testaufzeichnung zurückzusetzen. Für dieses kurze Szenario kann man die Änderungen auch manuell rückgängig machen. Dazu sind folgende Schritte durchzuführen:

Browser starten.
Aufruf der Seite http://www.unrisk.com/unriskfactory/pages/admin/overview.do im Browser.
Login mit Benutzername „oeller“ und Passwort „oeller“.
Klicken des Links „Instruments“ im horizontalen Menu oben.
Klicken des Links „IR Types/Average Rate Floaters“ im vertikalen Menu links.
Danach erscheint eine Tabelle im zentralen Bereich, und in der Zeile, in der die Spalte „Name“ den Wert „Test WebTEST1“ enthält, muss rechts auf den „Edit“-Link geklickt werden.
Nun erscheint wieder eine Tabelle, die es erlaubt, die Eigenschaften des Objekts zu ändern.
Ändern des Felds ISIN auf „Test WebTEST1“ anstelle von „Test WebTEST_1“.
Die Änderungen durch betätigen des Buttons „Save Changes“ bestätigen.
Zuletzt noch über den Link „Logout“, äußerst rechts oben, ausloggen.
Den Browser wieder schließen.

Nun ist die SUT, hier UnRisk-FACTORY, wieder im gleichen Zustand, wie vor der Aufnahme des Tests. Der Test kann also ausgeführt werden und sollte die gleichen Ergebnisse liefern. Zum Ausführen wechselt man wieder in die „Test“-Perspektive. Dort sieht man links die Test-Navigator-Ansicht. In dieser kann man mit einem Klick der rechten Maustaste über dem Element „Demo_WebTEST/Web-TEST Suite/Demo_WebTEST“ das Kontextmenu öffnen. Im Kontextmenu muss die Aktion „Run As/Test“ ausgewählt werden. Darauf hin wird dem Benutzer der in Abbildung 3.39 dargestellt Fortschrittsdialog angezeigt.

Abbildung 3.39: Die Ausführung des Tests

Während des Ausführens des Tests werden alle Requests, wie sie in der „Behavior“-Seite des Test-Editors definiert wurden, abgespielt. Wenn zu einem Request eine Assertion zugeteilt wurde, dann wird der Response dieses Request mit der Assertion verglichen und eine Statusmeldung wird erzeugt. Weiters werden zusätzlich noch alle einzelnen Vergleichsresultate der Kriterien und Basiskriterien in das Testprotokoll abgespeichert. Auch die dynamischen Request-Parameter werden aus den Responses gelesen und in den Requests verwendet. Am Ende erhält man ein Testprotokoll mit dem Namen der Testressource. In Abbildung 3.39 wird im Test-Navigator oberhalb der Testressource bereits das Protokoll unter dem Namen „Demo_WebTEST“ und dem Icon angezeigt. Das Fragezeichen bedeutet, dass die Testausführung noch nicht fertig ist und noch kein Entscheid über Erfolg oder Misserfolg gegeben werden kann.

Kontrolle der Ergebnisse

Das Testprotokoll kann durch einen Doppelklick auf die neu hinzugekommen Testprotokoll-Ressource “Demo_WebTEST” geöffnet werden. Zum Öffnen wird, wie in Abbildung 3.40 dargestellt, der TPTP-Testprotokoll-Editor verwendet.

Abbildung 3.40: Das Testprotokoll im Testprotokoll-Editor

Dieser Editor zeigt auf der Seite „Events“, welche Requests erfolgreich waren (Verdict=“successful“), welche nicht ausgeführt werden konnten (Verdict=“error“) und welche Requests eine Assertion nicht erfüllen konnten (Verdict=“fail“). In diesem Anwendungsfall wurde nur eine Assertion nicht erfüllt und zwar im Request „5 GET Average Rate Floater Details“. Um herauszufinden, warum die Assertion nicht erfolgreich erfüllt wurde, kann der Text im Textfeld „Text“ des Testprotokoll-Editors in einen Texteditor oder in die „Console“-Ansicht von Eclipse kopiert werden. Quelltext 3.1 zeigt einen Ausschnitt dieser Meldung an.

junit.framework.AssertionFailedError: No Success Verdicts!

Failure Verdicts:

Assertion Exectuion Result:

Assertion [id=-64663237:120568d644e:-7fd5, name='BA View Assertion 0', description='Auto Generated Assertion from BA View for BA expresseion: BA Expression [elements: //table[@class='details']//tr, name: th, value: td]', genericCriterions=[...]]

Assertion Execution: Failure

Reason:

1.) Criterion 'Currency' not found!

Criterion 'Name' found!

Criterion 'ISIN' found!

Criterion 'Comment' found!

…

Execution Text:

1.) Failure: Attribute 'Currency' could not match value 'USD' in response. Instead found value 'EUR'

Success: Attribute 'Name' matched value 'Test WebTEST1' in response!

Success: Attribute 'ISIN' matched value 'Test WebTEST1' in response!

Success: Attribute 'Comment' matched value 'test Web-TEST Inst1' in response!

…

Quelltext 3.1: Auszug aus dem Testprotkoll für den Request „5 GET Average Rate Floater Details“

Dabei wird der Status aller Assertions, Kriterien und Basiskriterien des aktuellen Requests („5 GET Average Rate Floater Details“) angegeben. Bei fehlgeschlagenen Basiskriterien wird auch der genaue Grund für das Fehlschlagen angegeben. Im Quelltext-Ausschnitt ist die Fehlermeldung für das Feld „Currency“ fett gesetzt.

Im Kapitel 3.3.4 „Bearbeiten der Assertions“ wurde bereits festgestellt, dass für den betroffenen Request ein BA-Kriterium mit dem Wert „USD“ für das Element „Currency“ überprüft wird, und dass dieses bei der Testausführung einen Fehler liefern muss. Web-TEST erkannte also diesen Fehler.

Das Schema des Testprotokolls und der Testprotokoll-Editor werden von TPTP definiert. Nähere Information können in der TPTP Dokumentation [12] nachgelesen werden. Im Rahmen einer späteren Version von Web-TEST ist geplant, den Testprotokoll-Editor zu erweitern, um dem Benutzer eine bessere Übersicht der nicht erfüllten Assertions zu liefern. Diese Erweiterung ist jedoch nicht mehr Teil dieser Arbeit.

4 Das TPTP-Framework

Die Eclipse Test-and-Performance-Tools-Platform (TPTP) bietet in erster Linie ein Framework für die Entwicklung von Test- und Performanzwerkzeugen auf Basis von Eclipse. Zusätzlich werden in TPTP auch vorgefertigte Werkzeuge für spezielle Testzwecke bereitgestellt. Angefangen von Werkzeugen für statische Codeanalysen und funktionale Tests, bis zu Laufzeitanalysen, Systemüberwachung und Performanztests. Aufgrund dieser zwei Ebenen von TPTP, einerseits als Testplattform und andererseits als Testwerkzeug, wird in TPTP auch zwischen zwei Zielgruppen unterschieden: Kunden und Anwender.

Abbildung 4.1: Die Zielgruppen und Verwendung von TPTP

Abbildung 4.1 stellt diese beiden Zielgruppen und ihre Rollen in TPTP dar. Als Kunden (Customer) werden dabei Personen oder Unternehmen bezeichnet, die mit Hilfe des TPTP-Frameworks neue Testwerkzeuge entwickeln. Als Anwender (User) werden Personen und Unternehmen bezeichnet, die eine SUT mit Hilfe von TPTP überwachen oder testen.

Weiters zeigt Abbildung 4.1, dass TPTP auf Eclipse basiert. Schließlich ist in der Abbildung noch dargestellt, dass die TPTP-Kunden zum Entwickeln von Testwerkzeugen auch die TPTP-Dienste verwenden können. Diese zusätzlichen Dienste werden in Form von Erweiterungspunkten und Datenmodellen zur Verfügung gestellt. Erweiterungspunkte sind Schnittstellen zum Hinzufügen neuer Funktionen in Eclipse oder in einem Eclipse-Plug-In. Mit Hilfe dieser Erweiterungspunkte können TPTP-Kunden das von TPTP angebotene Framework erweitern, um relativ einfach neue Test- und Überwachungswerkzeuge zu erstellen. Durch die Verwendung von TPTP können die verschiedenen erstellten Testwerkzeuge auch interagieren. Um dies zu bewerkstelligen, verwenden sie unter anderem die standardisierte Datenmodelle und Ablaufprozesse von TPTP.

TPTP selbst bietet, wie zuvor schon erwähnt, bereits einige Test- und Performanzwerkzeuge und kann daher auch ohne zusätzliche Erweiterungen verwendet werden, um eine Software zu testen beziehungsweise zu überwachen. Das vorrangige Ziel der in TPTP integrierten Werkzeuge ist allerdings, zu demonstrieren wie TPTP erweitert wird. Die Werkzeuge sind deshalb teilweise nicht für den produktiven Einsatz vorgesehen. Hier wird jedoch eindeutig die Zielsetzung von TPTP hervorgehoben: eine Plattform für Dritte bereit zu stellen, die es erlaubt, Test- und Performanzwerkzeuge zu erstellen, die dann durch gemeinsame, standardisierte Modelle und Verfahren miteinander kommunizieren können [13].

4.1 Die Architektur von TPTP

TPTP steht unter einer freien Lizenz, der Eclipse-Public-License (EPL), zur Verfügung und kann daher sowohl für kommerzielle Projekte als auch für Projekte im Open-Source-Bereich eingesetzt werden. Die Benutzeroberfläche von TPTP basiert auf Eclipse beziehungsweise der Eclipse Rich-Client-Platform (RCP) [22]. Weiters wird mit Hilfe des Eclipse-Modeling-Framework (EMF) [23] eine standardisierte Programmierschnittstelle für die in TPTP verwendeten Datenmodelle angeboten. Es werden viele weitere Eclipse-Dienste von TPTP benützt und die Installation von Eclipse ist deshalb eine Voraussetzung für TPTP.

4.1.1 Integration von TPTP in Eclipse

Abbildung 4.2: Eclipse Top-Level-Projekte (vergleiche [2] Seite 3)

Abbildung 4.2 zeigt die Eclipse Top-Level-Projekte, wie diese in der Präsentation „Eclipse Test & Performance Tools Platform (TPTP) Project – Project Structure“ [24] von Tyler Thessin, dem Leiter des TPTP-Projekt-Teams, aufgelistet werden. Diese Präsentation zeigt unter anderem, dass TPTP zu den Top-Level-Projekten zählt. Dadurch wird festgelegt, dass TPTP den Eclipse-Entwicklungszyklus mitmacht. Es steht also für eine aktuelle Eclipse-Version immer auch eine passende TPTP-Version zur Verfügung.

4.1.2 Die Komponenten von TPTP

Abgerundetes Rechteck: Test Abgerundetes Rechteck: Trace and Profile Abgerundetes Rechteck: Monitoring Abgerundetes Rechteck: BIRT Reporting

Abbildung 4.3: Die Komponenten von TPTP (siehe [6] Seite 16)

Wie Abbildung 4.3 darstellt, besteht TPTP aus fünf Teilen, die in weitgehend voneinander unabhängige Projekte gegliedert sind. Die dargestellten Projekte erfüllen folgende Aufgaben:

Platform-Projekt (erforderlich für TPTP): Dieses Projekt (in der Abbildung horizontal dargestellt) stellt allgemeine Dienste zur Verfügung, die von den anderen Projekten erweitert werden.
Test-Projekt (optional in TPTP): Dieses Projekt erlaubt das Definieren von funktionalen Tests, deren Ausführung und die Kontrolle der Ergebnisse.
Trace-and-Profiling-Projekt (optional in TPTP): Das Projekt erlaubt es, Execution-Stack- und Heap-Speicher-Informationen von Java-Anwendungen zu sammeln und in diversen Diagrammen dazustellen. Dadurch können beispielsweise die zeit- oder speicherintensivsten Funktionen ermittelt werden.
Monitoring-Projekt (optional in TPTP): Dieses Projekt stellt Dienste zum Sammeln, Analysieren und Darstellen von Laufzeitinformationen wie beispielsweise CPU- oder Speicherauslastung zur Verfügung.
BIRT-Reporting (Business Intelligence and Reporting Tools - optional in TPTP): Dieses Projekt integriert BIRT [25] in TPTP. BIRT-Reporting ist ein eigenständiges Eclipse-Plug-In und kann mit Hilfe der TPTP-BIRT-Schnittstelle von TPTP verwendet werden. Dieses Projekt ist in Abbildung 4.3 mit einer nicht-durchgezogenen Umrahmung gezeichnet, weil es sich um ein eigenständiges Eclipse-Plug-In handelt, das von TPTP verwendet werden kann. Mit Hilfe des BIRT-Reporting-Plug-Ins können benutzerspezifische Berichte definiert werden, um die aufgezeichneten Daten oder Testergebnisse grafisch oder tabellarisch aufzubereiten.

Die in der Abbildung 4.3 grün markierten TPTP-Projekte, das Platform-Projekt und das Test-Projekt, sind erforderlich für die Erweiterung durch Web-TEST und werden im Folgenden näher beschrieben.

4.2 Das Platform-Projekt

Das Platform-Projekt stellt standardisierte Datenmodelle, allgemeine Infrastrukturdienste, Datensammlungs- und Kommunikationsdienste, sowie ein Execution-Environment zur Verfügung. Das Execution-Environment erlaubt es, Dienste auf entfernten Rechnern auszuführen und zu steuern und wird im Kapitel 4.2.1 „Das TPTP-Execution-Environment“ näher beschrieben. Weiters stellt das Platform-Projekt Eclipse-Erweiterungspunkte und auch Execution-Environment-Erweiterungspunkte zur Verfügung. Wie zuvor schon erwähnt, basiert die gesamte Datenverarbeitung der TPTP-Projekte auf den im Platform-Projekt definierten Datenmodellen. Dabei werden folgenden Datenmodelle im Platform-Projekt definiert:

Trace-Datenmodell: Dieses Datenmodell wird für das Sammeln von Execution-Stack- und Heap-Speicher-Informationen verwendet.
Test-Datenmodell: Dieses Modell besteht selbst wieder aus mehreren Teilmodellen und dient zum Definieren von Testfällen und Testverhalten, sowie zum Übertragen und Speichern der Testergebnisse.
Generical-Statistical-Datenmodell: Dieses Datenmodell dient zum Überwachen von verschiedenen numerischen Parametern über die Zeit. Zum Beispiel können Speicher- und CPU-Auslastung mit Hilfe dieses Datenmodells erfasst werden.
Log-Datenmodell: Dieses Datenmodell wird zum Speichern von Common-Base-Events [26] verwendet.

Besonders interessant im Zusammenhang mit Web-TEST ist das Test-Datenmodell. Dieses wird deshalb in einem eigenen Kapitel 4.4 „Die Datenverwaltung im TPTP-Test-Projekt“ noch näher erklärt. Das Platform-Projekt stellt auch die EMF-basierte Programmierschnittstelle für die Datenmodelle bereit. Die eigentliche Speicherung der Daten erfolgt dabei in einer XML-Datei, die zur effizienteren Speichernutzung komprimiert wird.

4.2.1 Das TPTP-Execution-Environment

Das Execution-Environment von TPTP wird sowohl für die Aufzeichnung von URL- und Automatischen-GUI-Tests als auch für das Abspielen aller Testtypen verwendet. Das Execution-Environment wird auch in den anderen TPTP-Projekten für diverse Remote-Dienste verwendet. Im Trace-And-Profiling-Projekt dient es zum Aufzeichnen der Log-Daten, im Monitoring-Projekt liefert es die zu überwachenden Werte und kann Einstellungen und Kommandos an die SUT übermitteln, und im Test-Projekt wird es wie gesagt zum Aufzeichnen und zum Abspielen der Tests verwendet.

Abgerundetes Rechteck: Workbench Machine Abgerundetes Rechteck: Target Machine

Abbildung 4.4: Das TPTP-Execution-Environment (vergleiche dazu [19] auf Seite 30)

Abbildung 4.4 zeigt den gesamten Aufbau des TPTP-Execution-Environments:

Workbench-Rechner (Workbench Machine): Dies ist der Rechner auf dem die Eclipse-Workbench läuft, die das Execution-Environment zum Ausführen eines Agenten (Agent) verwenden will.

TPTP-Client-Bibliothek (TPTP Client Library): Diese Bibliothek kümmert sich um die Kommunikation mit dem Agent-Controller.
Ziel-Rechner (Target Machine): Auf dem Ziel-Rechner wird üblicherweise die SUT ausgeführt, die mittels eines Agenten überwacht bzw. gesteuert werden soll. Auf diesem Rechner muss weiters der Agent-Controller installiert werden. Bei der Verwendung des Test-Projekts, insbesondere bei der Verwendung von Web-TEST, ist es üblich, dass Workbench- und Ziel-Rechner der selbe Rechner sind. Dies resultiert aus der Verwendung eines Web-Browsers zur Testaufnahme, der selbst wieder mit einem entfernen Server kommunizieren kann.
Agent-Controller (Agent Controller): Der Agent-Controller ermöglicht es, die Agenten auf dem Ziel-Rechner zu starten und zu steuern. Außerdem übermittelt dieser die von der TPTP-Client-Bibliothek angeforderten Werte der Agenten an den Workbench-Rechner.
Agenten (Agents): Agenten stellen Funktionen auf dem Zielrechner zur Verfügung, beispielsweise Überwachungsdienste oder das Ausführen eines Tests. Wie man in Abbildung 4.4 erkennt, müssen sich die Agenten nicht mehr um die Kommunikation zwischen den beiden Rechnern kümmern. Die für die Testaufnahme und für das Abspielen der Web-TEST-Tests benötigten Agenten werden bereits im Test-Projekt definiert und können in Web-TEST weiter verwendet werden.

Der Remote-Agent-Controller (RAC) und der Integrated-Agent-Controller (IAC)

Der Agent-Controller ist ein eigener Prozess und steht in zwei Ausführungen, als Remote-Agent-Controller (RAC) und als Integrated-Agent-Controller (IAC), zur Verfügung. Der RAC unterstützt die Ausführung und Überwachung von Agenten auf entfernen Rechnern und muss separat auf dem Ziel-Rechner installiert werden. Eine detaillierte Beschreibung der Installation des RAC findet man unter [27]. Der IAC wird hingegen automatisch mit TPTP installiert und kann Agenten auf dem lokalen Rechner ausführen. In Kapitel 3.3.1 „Aufzeichnen eines Tests“ wurde bereits die Konfiguration dieses internen Agent-Controllers angesprochen. Der Proxy-Dienst, der zur Aufnahme des Web-TEST-Tests im gezeigten Anwendungsfall diente, ist ein Agent, der vom IAC gesteuert wurde. Der IAC-Prozess wird dabei automatisch bei Bedarf von TPTP gestartet.

In den beiden Agent-Controllern, IAC und RAC, sind bereits Standard-Agenten für einige Dienste, wie etwa zum Abspielen eines Tests, vorinstalliert. Das Execution-Environment selbst muss deshalb von Web-TEST nicht mehr erweitert werden. Eine detaillierte Beschreibung des Execution-Enviornments wird somit in dieser Arbeit nicht benötigt, ist jedoch unter [13] verfügbar.

4.3 Das Test-Projekt

Das Test-Projekt stellt Agenten zur Verfügung, um Tests aufnehmen und ausführen zu können sowie Dienste zum Editieren von Testdefinitionen. Standardmäßig werden vier Testtypen unterstützt:

JUnit-Test
Manual-Test
URL-Test
Automated-GUI-Test

Der Autor dieser Arbeit testete für die Firma MathConsult diese vier Testtypen. Dabei wurde versucht, Regressionstests für die Webanwendung UnRisk-FACTORY zu erstellen. Keiner dieser Testtypen konnte das Entwicklungsteam von UnRisk-FACTORY überzeugen. Es wurde jedoch festgestellt, dass eine Kombination des URL-Tests und des Automated-GUI-Tests die gewünschten Funktionen bieten würde. Web-TEST versucht deshalb, diese Kombination umzusetzen.

Es folgt nun eine kurze Beschreibung der einzelnen Testtypen, um einen Überblick über die von TPTP zur Verfügung gestellten Testfunktionen zu gewinnen. Weiters werden die Testtypen, insbesondere der URL-Test und der Automated-GUI-Test, mit dem Web-TEST-Testtyp vergleichen. Dabei wird auch erkennbar, warum eine Kombination dieser beiden Testtypen die von Web-TEST geforderte Funktionalität erfüllen kann.

4.3.1 TPTP-JUnit-Test

Ein TPTP-JUnit-Test ist eine Hülle für einen Standard-JUnit-Test. Mit Hilfe dieser Hülle können die TPTP-Dienste auch für JUnit-Tests verwendet werden. Beispielsweise kann man die Testdefinition in einem grafischen Editor verwalten. Man kann den Test auf einem entfernten Rechner (einem Remote-Rechner) ausführen, und man kann die Testergebnisse aufzeichnen, grafisch darstellen und für benutzerdefinierte BIRT-Berichte verwenden. Eine „Hülle“ für einen JUnit-Test bedeutet in diesem Zusammenhang, dass der JUnit-Test in ein TPTP-Test-Datenmodell, wie im Kapitel 4.4.1 „Das Modell der Testdefinition“ beschrieben, abgebildet wird.

Abbildung 4.5: Der grafische Editor für TPTP-JUnit-Tests (siehe die Demonstration unter [28])

Abbildung 4.5 zeigt den grafischen Test-Editor für TPTP-JUnit-Tests. Dort können Informationen wie Name, Beschreibung und die zugrundeliegende JUnit-Testklasse eingestellt werden. Weiters können auf der Editorseite „Test Methods“ Testmethoden hinzugefügt und entfernt werden. Schließlich kann auf der „Behavior“-Seite auch die Ausführungsreihenfolge festgelegt werden. Die Definition (also der Code) der Testmethoden muss weiters manuell in der zugrundeliegenden JUnit-Klasse erstellt werden. Das Ausführen funktioniert genau wie beim Web-TEST-Test. Eine Demonstration des TPTP-JUnit-Tests, die dies alles veranschaulicht, ist unter [28] verfügbar. Wenn man diese Demonstration mit dem Anwendungsfall des Web-TEST-Tests im Kapitel 3.3 „Ein Anwendungsfall für Web-TEST“ vergleicht, so erkennt man, dass sehr viele Schritte identisch sind. Durch die Verwendung von TPTP wird ein einheitlicher Testprozess anwendbar.

4.3.2 TPTP-Manual-Test

Der TPTP-Manual-Test ist ein manueller Test. Das heißt, er wird nicht programmgesteuert abgespielt, sondern muss von einem Tester abgespielt werden. Ein manueller Test ist hier eine textuelle Beschreibung eines Tests. Sie besteht aus folgenden Teilen:

einer Beschreibung welche Aktion ein Tester in der SUT ausführen muss,
einer Definition der Reihenfolge dieser Aktionen
und einer Beschreibung welche Ergebnisses der Tester kontrollieren muss.

Dabei wird die Testbeschreibung wieder in einem TPTP-Test-Datenmodell abgebildet, wodurch die TPTP-Dienste auch für den Manual-Test verwendet werden können.

Abbildung 4.6: Der Test-Editor für TPTP-Manual-Tests (siehe Demonstration unter [29])

Abbildung 4.6 zeigt den TPTP-Manual-Test-Editor, der es erlaubt, die Testbeschreibung für den Manual-Test zu erstellen. Dieser Test-Editor sieht den Test-Editoren von TPTP-JUnit-Test und Web-TEST-Test sehr ähnlich. Es wird eben bei allen Testtypen das gleiche Datenmodell verwendet. Zusätzlich zum Test-Editor wird beim Manual-Test eine Manual-Test-Client-Anwendung, wie sie in Abbildung 4.7 dargestellt ist, zur Verfügung gestellt. Diese Anwendung ist als Agent des Execution-Environments realisiert. Sie erweitert also das Execution-Environment und wird mit dem Test-Projekt in den IAC installiert.

Abgerundetes Rechteck: Status Abgerundetes Rechteck: Stopp-Button

Abbildung 4.7: Die Manual-Test-Client-Anwendung für den Tester (siehe Demonstration unter [29])

Der Manual-Test-Client-Agent wird vom Execution-Environment auf dem Ziel-Rechner gestartet. Das ist der Rechner auf dem die SUT läuft. Die Eclipse-Workbench auf dem Workbench-Rechner (dargestellt in Abbildung 4.6) überwacht die Testausführung und kommuniziert mit dem Manual-Test-Client-Agent. Der Tester, der vor dem Ziel-Rechner sitzt, sieht im Manual-Test-Client die abzuarbeitenden Testschritte und deren Beschreibung. Mit Hilfe dieser Information kann er den Test in der SUT durchspielen und den Status zu den einzelnen Testschritten notieren. Sobald der Tester mit dem gesamten Test fertig ist, klickt er auf den Stopp-Button (). Dann wird über das Execution-Environment die Eclipse-Workbench von der Fertigstellung des Tests informiert und die Testergebnisse können wieder im TPTP-Testprotokoll-Editor betrachtet werden. Bemerkenswert ist, dass für den Benutzer der Eclipse-Workbench der Test genau gleich abläuft wie bei den anderen Testtypen, dass jedoch der eigentliche Test auf dem Ziel-Rechner manuell durchgeführt wird.

4.3.3 TPTP-URL-Test

Ein TPTP-URL-Test besteht, wie auch ein Web-TEST-Test, aus einer Anzahl von HTTP-Requests, die während des Tests in einer bestimmten Reihenfolge abgespielt werden. Allerdings stehen beim URL-Test weder die gespeicherten Responses noch Assertions zur Verfügung. Der URL-Test ist deshalb nicht für das funktionale Testen auf Basis der Inhalte von HTML-Seiten geeignet. Vielmehr kann man die Performanz, insbesondere die Antwortzeiten, mit diesem Testtyp feststellen. Dazu kann man die Anzahl der simulierten Testbenutzer einstellen. Wenn ein Test gleichzeitig mehrfach ausgeführt werden soll, so kann die Benutzerzahl erhöht werden. Damit kann man beispielsweise das Ansteigen der Antwortzeit bei steigender Auslastung messen. Standardmäßig ist, wie Abbildung 4.8 zeigt, die Benutzerzahl (Users) auf „1“ gesetzt.

Abgerundetes Rechteck: Benutzeranzahl

Abbildung 4.8: Der Editor für TPTP-URL-Tests (siehe Demonstration unter [30])

Eine URL-Test-Definition wird mit Hilfe des in Abbildung 4.8 dargestellten URL-Test-Editors editiert. Der URL-Test kann jedoch auch mit Hilfe des im Kapitel 3.3.1 „Aufzeichnen eines Tests“ beschriebenen Recorders erstellt werden. Dazu muss während der Aufzeichnung der Test-Generator „TPTP URL Test Generator“ verwendet werden.

Da der URL-Test keine Response-Daten speichert, fehlen hier gegenüber dem Web-TEST-Test-Editor alle Seiten, die sich auf den Response beziehen. Außerdem stehen die Editor-Aktionen des Web-TEST-Test-Editors nicht zur Verfügung. Man kann jedoch wie beim Web-TEST-Test-Editor zusätzliche Requests hinzufügen und die Ausführungsreihenfolge definieren. Auch das Starten der Testausführung und das Betrachten der Ergebnisse funktioniert wie beim Web-TEST-Test. Im Gegensatz zum Web-TEST-Test werden während der Testausführung keine Überprüfungen bezüglich des Inhalts der Responses durchgeführt.

Der URL-Testtyp diente als Vorlage für die Entwicklung des Web-TEST-Tests. Deshalb ist ein Web-TEST-Test eine Obermenge des URL-Tests und bietet auch alle Funktionen eines URL-Tests an. Mit Hilfe der Demonstration des URL-Tests unter [30] kann man einen Überblick über die Funktionen dieses Testtyps gewinnen. Wenn man die beiden Demonstrationen, [30] für den URL-Test und Kapitel 3.3 „Ein Anwendungsfall für Web-TEST“ für den Web-TEST-Test, vergleicht, dann werden die Gemeinsamkeiten und Unterschiede der Testtypen deutlich. Die Unterschiede ergeben sich vor allem wegen der unterschiedlichen Zielsetzung der Testtypen: der URL-Test dient zur Analyse der Performanz und der Web-TEST-Test für Regressionstests von HTML-basierten Webanwendungen.

4.3.4 TPTP-Automated-GUI-Test

Der Automated-GUI-Test dient zum Erstellen von Regressionstests für Eclipse selbst und für Eclipse-Plug-Ins. Man kann mit Hilfe eines Recorders einen Testfall während der Benützung von Eclipse aufzeichnen. Der Test wird in eine XML-Beschreibung umgewandelt, die die einzelnen Kommandos enthält, und man kann Verifikationspunkte einfügen. Die XML-Beschreibung kann später automatisch ausgeführt werden. Dabei wird der Test programmgesteuert durchgeführt. Außerdem werden die Verifikationspunkte überprüft. Beispielsweise könnte ein Verifikationspunkt sein, dass überprüft wird, ob bestimmte Ressourcen erzeugt oder Nachrichten ausgegeben wurden.

Abbildung 4.9: Der Editor für TPTP-Automated-GUI-Tests (siehe Demonstration unter [12])

Abbildung 4.9 zeigt die „Test Cases“-Seite des Automated-GUI-Test-Editors. Hier wurde das Erstellen eines Java-Projekts in Eclipse mit Hilfe eines GUI-Recorders aufgezeichnet und in eine XML-Beschreibung umgewandelt. In der Abbildung wird die XML-Beschreibung unter dem Punkt „Macro“ auf der rechten Hälfte des Editors angezeigt. Rechts oben ist der Start-Button () des Recorders. Damit kann der in Abbildung 4.10 dargestellte GUI-Recorder gestartet werden.

Abbildung 4.10: TPTP-GUI-Recorder

Der GUI-Recorder wird wieder über den Agent-Controller in einem nicht-modalen Dialog geöffnet. Der Tester verwendet dann Eclipse normal weiter und alle Aktionen werden aufgezeichnet. Beendet wird die Aufzeichnung über den Stopp-Button () des Recorders. Der Recorder erstellt nach dem Beenden einen neuen Testfall mit der XML-Beschreibung und fügt ihn zum aktiven Automated-GUI-Test hinzu. Die Reihenfolge der Tests kann dann wieder auf der Seite „Behavior“ des Test-Editors eingestellt werden. Das Ausführen des Tests funktioniert genau wie bei den anderen Testtypen. Für nähere Informationen über den Automated-GUI-Test empfiehlt sich die Demonstration unter [30] und die dort referenzierte Literatur.

4.4 Die Datenverwaltung im TPTP-Test-Projekt

Alle Testtypen des Test-Projekts verwenden zum Speichern und Verwalten der Testdaten ein gemeinsames, standardisiertes Datenmodell. Dieses Datenmodell wird, wie alle TPTP-Datenmodelle, durch das Platform-Projekt zur Verfügung gestellt und ist eine Referenzimplementierung des UML-2.0-Testing-Profiles [32]. Das Modell besteht wieder aus drei Teilmodellen:

Aus dem Modell für die Testdefinition, das den Aufbau eines Tests beschreibt.
Aus dem Modell für das Testverhaltens, das festlegt wie ein Test abläuft.
Aus dem Modell für die Testausführung, auch als Testlog-Modell oder Execution-History-Modell bezeichnet, das die Ergebnisse der Testausführungen abbildet.

Im Folgenden werden die drei Teilmodelle mit Hilfe von Ausschnitten aus dem jeweiligen Teilmodell erklärt. Dazu werden die UML2-Infrastructur-Notation [33] und die UML2-Sequenzdiagramm-Notation [34] verwendet. Eine grobe Kenntnis dieser Notationen wird hier vorausgesetzt. Weiters ist zu beachten, dass die Ausschnitte stark vereinfacht wurden, um die Übersichtlichkeit zu erhalten. Dabei wird unter anderem die farbliche Codierung der Modell-Typen ignoriert. Eine vollständige Beschreibung der TPTP-Test-Projekt-Datenmodelle ist unter [35] nachzulesen.

4.4.1 Das Modell der Testdefinition

Das Modell der Testdefinition (im Folgenden kurz Test-Modell genannt) ist eine Implementierung des UML-2.0-Test-Profiles und beschäftigt sich mit der Modellierung der Testkomponenten, der Teststruktur, der Testbeschreibung und der Zusammenstellung von Tests zu Testgruppen. Abbildung 4.11 zeigt einen Ausschnitt der Modelldokumentation des Test-Modells.

Abbildung 4.11: Das Test-Modell

Die Bedeutung der im Ausschnitt dargestellten Relationen ist wie folgt:

Test (TPFTest): Ein Test ist ein abstraktes Konzept für Testfälle (TPFTestCase) und Testsuiten (TPFTestSuite). Ein Test enthält eine Menge von Testzielen (TPFTestObjective), einen Testtyp (type) und eine Testverhaltens-Definitionen (TPFBehavior). Weiters sind mit dem Test auch die Ausführungsergebnisse des Tests (TPFExecutionResult) verknüpft.
Testfall (TPFTestCase): Ein Testfall beschreibt, welche Funktion der SUT getestet wird und wie diese getestet wird. Dabei werden neben der zu testenden Funktion auch die Eingabeparameter und die zu erwartenden Ergebnisse festgelegt. Diese Eigenschaften werden im Testverhalten (TPFBehavior) des Testfalls definiert. Ein Testfall ist immer Teil einer Testsuite (TPFTestSuite).
Testsuite (TPFTestSuite): Eine Testsuite ist ein Gruppierungsmechanismus für Testfälle. Zusammengehörige Testfälle, die ein bestimmtes Testmotiv verfolgen, werden üblicherweise zu einer Testsuite gruppiert.
Testziel (TPFTestObjective): Das Testziel gibt das Motiv bzw. Ziel des Tests an.
Testergebnis (TPFExecutionResult): Das Ergebnis eines Tests enthält die Daten, die bei der Testausführung gesammelt werden: Test-Deployment-Informationen, Log-Nachrichten und der Status der Testausführung. Der Status wird dabei sowohl für die gesamte Testsuite als auch für jeden einzelnen Testfall aufgezeichnet. Folgende Werte stehen für den Status zur Verfügung:

Error: bezeichnet einen Fehler in der Testausführung
Failure: steht für eine fehlgeschlagene Bedingung. Im Web-TEST-Test beispielsweise für eine fehlgeschlagene Assertion.
Successful: bedeutet, dass in dieser Testsuite oder diesem Testfall weder ein Error-Status noch ein Failure-Status aufgetreten ist und der Test deshalb erfolgreich war.

Testverhalten (TPFBehavior): Das Testverhalten wird im TPTP-Modell als Sequenzdiagram modelliert und enthält die Interaktionen zwischen einer Testkomponente und der SUT. Weiters werden im Testverhalten alle Ein- und Ausgabeparameter für die Interaktionen festgelegt. Es wird dabei sowohl für die einzelnen Testfälle als auch für die Testsuite ein Verhalten definiert. Abbildung 4.11 veranschaulicht das durch den abstrakten Typ „Test“, der sowohl für „Testfall“ aus auch für „Testsuite“ stehen kann. Das Gesamtverhalten der Testsuite ergibt sich aus dem Verhalten der darin referenzierten Testfälle und deren Verhalten.

4.4.2 Das Modell des Testverhaltens

Das Modell des Testverhaltens (im Folgenden auch Behavior-Modell genannt) beschäftigt sich mit der Definition des Verhaltens eines Testobjekts. Als Metapher für das Behavior-Modell dient das UML-Sequenzdiagramm. Deshalb sind die wesentlichen Typen des TPTP-Behavior-Modells ähnlich den Typen in einem UML-Sequenzdiagramm.

Nachricht

Interaktionsoperanden

Kombiniertes Interaktionsfragment

Lebenslinie

Interaktion

Abbildung 4.12: Grafische Darstellung eines UML-Sequenzdiagramm

Abbildung 4.12 zeigt ein Sequenzdiagramm mit den Elementen die auch im Behavior-Modell verwendet werden. Abbildung 4.13 und Abbildung 4.14 zeigen im Gegensatz dazu Ausschnitte aus dem Behavior-Modell. Die darin verwendeten Elemente sind äquivalent zu den Elementen des Sequenzdiagramms. Deshalb lassen sich mit Hilfe des Sequenzdiagramms die im Behavior-Modell verwendeten Elemente leicht verstehen.

Abbildung 4.13: Kernelemente des Behavior-Modells

Abbildung 4.13 stellt einen Ausschnitt des Behavior-Modells dar. Dabei werden die darin enthaltenen Typen im Rahmen des TPTP-Test-Projekts wie folgt verwendet:

Testverhalten (TPFBehavior): Der Typ Testverhalten wurde bereits im Kapitel 4.4.1 „Das Modell der Testdefinition“ erläutert. Er stellt das Verhalten eines Testfalls oder einer Testsuite dar.
Interaktion (BVRInteraction): Eine Interaktion ist genau einem Testverhalten zugeteilt und umgekehrt kann ein Testverhalten maximal eine Interaktion beinhalten. Die Interaktion besteht aus einer Menge von Lebenslinien (BVRLifeline) und Interaktionsfragmenten (BVRInteractionFragment). Eine Interaktion ist dementsprechend das Equivalent zum UML-Sequenzdiagramm.
Lebenslinie (BVRLifeline): Eine Lebenslinie stellt einen einzelnen Teilnehmer an der Interaktion dar und referenziert alle mit dem Teilnehmer verbunden Interaktionsfragmente (BVRInteractionFragment).
Interaktionsfragmente (BVRInteractionFragment): Das Interaktionsfragment ist ein abstraktes Konzept, um einen Teil des Verhaltens einer Interaktion zu beschreiben. Ein Interaktionsfragment entspricht einem vertikalen Ausschnitt aus einem UML-Sequenzdiagramm. In Abbildung 4.12 sind etwa die Elemente „Kombiniertes Interaktionsfragment“ und „Interakationsoperand“ spezielle Interaktionsfragmente. Der genaue Unterschied dieser zwei Interaktionsfragmente bedarf etwas genauerer Betrachtung und wird in Abbildung 4.14 veranschaulicht und im Folgenden erklärt.
Man erkennt in Abbildung 4.12 (das Sequenzdiagramms) auch, dass Interaktionsfragmente Nachrichten (BVRMessage) enthalten. Weiters kann ein Interaktionsfragment im Behavior-Modell ein anderes Testverhalten (TPFBehavior) referenzieren. In Abbildung 4.13 wird deshalb eine optionale Verbindung mit dem Testverhalten (otherBehavior) gezeigt. Diese Relation wurde in der Abbildung 4.13 zur besseren Erkennbarkeit blau umrahmt. Mit Hilfe dieser Beziehung kann das Testverhalten der Testsuite auf das Testverhalten der einzelnen Testfälle zugreifen. Das Prinzip entspricht der Einbettung von Sequenzdiagrammen in ein übergeordnetes Sequenzdiagramm.
Nachricht (BVRMessage): Eine Nachricht definiert eine Kommunikation zwischen einem Sender- und einem Empfänger-Interaktionsfragment (BVRMessageEnd). Dabei kann eine Nachricht das gleiche Interaktionsfragment als Sender und Empfänger enthalten. Weiters enthält eine Nachricht einen Nachrichtentyp (BVRMessageSort), der angibt, ob die Nachricht synchron oder asynchron ist.
Nachrichtenende (BVRMessageEnd): Ein Nachrichtenende repräsentiert das Verhalten am Ende oder am Anfang einer Nachricht. Da es sich hier wieder um ein Verhalten handelt, ist das Nachrichtenende von Interaktionsfragment abgeleitet.

Abbildung 4.14: Ausschnitt aus den Elementen des Interaktionsoperand im Behavior-Modell

Abbildung 4.14 zeigt, wie ein Interaktionsoperand des Sequenzdiagramms im Behavior-Modell eingebunden werden kann. Damit können beispielsweise Schleifen (Loops) realisiert werden. Weiters wird dargestellt, wie die Eigenschaften der Tests, etwa Eingabeparameter, abgespeichert werden können. Die in Abbildung 4.14 dargestellten Typen haben dabei folgende Bedeutung:

Interaktionsfragment (BVRInteractionFragment): Das Interaktionsfragment wurde bereits im Rahmen der Abbildung 4.13 erklärt. In Abbildung 4.14 ist jedoch erkennbar, dass ein Interaktionsfragment zusätzlich eine Menge von Eigenschaften (BVRProperty) enthalten kann. Diese Eigenschaften beschreiben im Test-Projekt üblicherweise Testeinstellungen und Eingabeparameter für Funktion, die getestet werden. Sie bestehen aus einem Namen und einem Wert.
Kombiniertes-Interaktionsfragment (BVRCombinedFragment): Das kombinierte Interaktionsfragment besteht aus einer Menge von Interaktionsfragmenten und einem Interaktionsoperator (BVRInteractionOperator), der angibt welche Art von Struktur verwendet wird: Schleife (Loop), Alternative (alt), Option (opt), Parallel (par), Negativ (neg). Die Bedeutung der Interaktionsstrukturen entspricht der Bedeutung im Sequenzdiagram und kann unter [34] nachgelesen werden. Diese Strukturen können einen oder mehrere Teile enthalten. Beispielsweise kann es in einer „Alternativen“-Struktur (alt-Interaktionsoperator) mehrere alternative Zweige geben. Die Zweige bzw. die Teile werden als Interaktionsoperanden (BVRInteractionOperand) realisiert.
Interaktionsoperand (BVRInteractionOperand): Ein Interaktionsoperand ist ein Teil eines Kombinierten-Interaktionsfragments und ist selbst wieder von Interaktionsfragment abgeleitet. Ein Interaktionsoperand ist weiters eine Zusammenstellung mehrerer Interaktionsfragmente. Dadurch kann ein strukturierter, hierarchischer Baum von Interaktionsfragmenten erstellt werden. Zusätzlich kann ein Interaktionsoperand eine Interaktionskonstante enthalten (BVRInteractionConstant). Diese gibt beispielsweise die Bedingung der Alternative oder die Schleifenbedingung an.

Das hier verwendete Schema für das Test- und Behavior-Modell scheint auf den ersten Blick zu komplex gewählt. Man würde wahrscheinlich, wenn man nur einen der TPTP-Testtypen betrachtet, ein einfacheres Modell verwenden. Das von TPTP gewählte allgemeine Modell hat jedoch einige Vorteile, welche die Komplexität aufwiegen:

Konformität zum UML-2.0-Testing-Profile
Einsetzbar für alle Testtypen
Die Kenntnis eines Testtypen erleichtert das Arbeiten mit allen anderen Typen
Testtypen können ineinander überführt werden
Testtypen können im Verarbeitungszyklus beispielsweise beim Abspielen gleich behandelt werden

4.4.3 Das Execution-History-Modell

Abbildung 4.15: Kernelemente des Execution-History-Modells

Das in Abbildung 4.15 dargestellte Modell beschreibt den Aufbau der Daten die bei der Testausführung gesammelt werden.

Testergebnis (TPFExecutionResult): Wie bereits im Test-Modell dargestellt, verweist das Testergebnis auf genau einen Test (TPFTest). Weiters enthält es auch genau eine Historie aller Events die während der Testausführung aufgetreten sind – die Test-Execution-Historie (TPFExecutionHistory). Das Testergebnis enthält auch den Testentscheid (TPFVerdict). Dieser gibt den Teststatus, wie in Kaptitel 4.4.1 „Das Modell der Testdefinition“ beschrieben, an.
Test-Execution-Historie (TPFExecutionHistory): Die Test-Execution-Historie ist eine Sammelung aller Test-Execution-Events (TPFExecutionEvent), die während der Testausführung auftreten.
Test-Execution-Event (TPFExecutionEvent): Ein Test-Execution-Event stellt ein einzelnes Ereignis innerhalb einer Testausführung dar. Test-Execution-Events können hierarchisch aufgebaut werden, wie die Vater-Kind-Beziehung (parent-child-Beziehung) in Abbildung 4.15 zeigt. Ein von Test-Execution-Event abgeleiteter Typ ist der Testenscheid-Event (TPFVerdictEvent). Dieser enthält zusätzlich zu den Test-Execution-Event-Eigenschaften auch einen Status und wird zum Bestimmen des Ergebnisses eines einzelnen Testfalls innerhalb des gesamten Tests verwendet. Beim Web-TEST-Test wird etwa ein Testentscheid-Event für jeden ausgeführten Request erzeugt. Falls alle Assertions des Requests erfüllt werden, wird ein Successful-Testenscheid-Event erzeugt. Falls jedoch auch nur eine Assertion fehlschlägt, so wird ein Failure-Testenscheid-Event erzeugt und auch das Testergebnis wird dann auf den Failure-Status gesetzt. Um die Verbindung zu dem Behavior-Modell des Tests zu gewährleisten, wird einem Test-Execution-Event auch ein Interaktionsfragment (BVRInteractionFragment) zugeteilt.

5 Die Umsetzung von Web-TEST

Das Testwerkzeug Web-Test baut auf dem TPTP-Framework auf. Dadurch ist es möglich, die Vorteile von TPTP in Web-TEST zu übernehmen. Besonders interessant sind dabei folgende Punkte:

Verwendung eines erprobten Testprozesses
Verwendung von standardisierten und verbreiteten Datenmodellen
Verwendung einer dem Benutzer vertrauten Benutzeroberfläche
Erweiterbarkeit und Anpassbarkeit des Werkzeugs
Einsparung von Entwicklungszeit durch Wiederverwendung der TPTP-Dienste

Web-TEST muss sich bestmöglich in TPTP integrieren, um diese Eigenschaften optimal an den Kunden weiterzugeben.

5.1 Integration von Web-TEST in TPTP und Eclipse

TPTP wurde als Dienstplattform für Erweiterungen konzipiert und bietet deshalb eine Fülle von Erweiterungspunkten an. Web-TEST nützt diese Erweiterungspunkte und kann dadurch den erprobten TPTP-Testprozess, die TPTP–Datenmodelle und andere TPTP-Dienste verwenden. Um die Integration in TPTP bestmöglich zu gestalten, wurden mit dem TPTP-Team folgende Kriterien für die Zusammenarbeit von TPTP und Web-TEST festgelegt:

Die TPTP-Datenmodelle dürfen nicht geändert - auch nicht erweitert - werden. Die zusätzlichen Datenstrukturen für Web-TEST müssen mit Hilfe von generischen Datentypen innerhalb des TPTP-Datenmodells realisiert werden.
Alle benötigten Daten zur Testdefinition und zur Testausführung müssen in der von TPTP vorgegebenen Testressource gespeichert werden.
Es dürfen keine Quellecode-Dateien und keine anderen Ressourcen verwendet werden, die nicht mit der EPL vereinbar sind.
Der Quellcode von Web-TEST muss selbst unter der EPL verfügbar sein.

Installiert wird Web-TEST als Eclipse-Feature, dass unter der Internet-Adresse https://sourceforge.net/projects/tptpwebtest/ verfügbar ist. Sourcefore.net bietet Entwicklern die Möglichkeit Open-Source-Projekte zu hosten. Für die Entwicklung und die Verbreitung von Web-TEST wurde auf sourceforge.net das Projekt TPTP-Web-TEST unter der oben angegebenen Internet-Adresse angelegt. Zurzeit steht ein Release der Version 1.0.0 zu Verfügung. Auch die vorliegende Arbeit ist über diese Internet-Adresse erhältlich.

Web-TEST erweitert nicht nur TPTP, sondern bietet Kunden auch neue Möglichkeit von Adaptionen und Erweiterungen an. Die neuen Erweiterungspunkte von Web-TEST werden im Kapitel 5.5 „Die angebotenen Erweiterungspunkte“ detailliert besprochen. Ein Web-TEST-Kunde kann also seine kundenspezifischen Testwerkzeuge auf einer noch höheren Abstraktionsebene erstellen. Abbildung 5.1 zeigt dementsprechend Web-TEST als eine weitere Schicht, zwischen den Kunden-Erweiterungen und dem TPTP-Framework.

Abbildung 5.1: Integration von Web-TEST in TPTP

Weiters zeigt Abbildung 5.1, dass die Anwender drei Möglichkeiten haben Web-TEST zu verwenden:

Sie können auf die von Web-TEST angebotenen Dienste zugreifen.
Sie können auch auf die reinen TPTP-Dienste zugreifen.
Sie können kundenspezifischen Erweiterungen verwenden, die auf Web-TEST und TPTP zurückgreifen.

5.2 Die Aufteilung von Web-TEST in Eclipse-Plug-Ins

Web-TEST besteht, wie auch die einzelnen TPTP-Projekte, aus einer Anzahl von Plug-Ins, die über ein Eclipse-Feature installiert werden können.

Abbildung 5.2: Die Plug-Ins von Web-TEST

Abbildung 5.2 zeigt alle Web-TEST-Plug-Ins und ihre Abhängigkeiten zu den TPTP-Plug-Ins. Es ist erkennbar, dass die Plug-In-Struktur von Web-TEST streng hierarchisch ist, wobei Web-TEST-Lib die Basis ist und Web-TEST-Business-Attribute-Criterion alle anderen Plug-Ins voraussetzt. Weiters ist die Abhängigkeit der Web-TEST-Plug-Ins zu ihren jeweiligen TPTP-Gegenstücken dargestellt. So hängt etwa Web-TEST-Models von Hyades-Models ab. Web-TEST-Core hängt von TPTP-Test-Framework und TPTP-Test-Tools ab, und Web-TEST-UI hängt von Hyades-UI, TPTP-Test-Framework-UI und TPTP-Test-Tools-UI ab. Die Linien der Abhängigkeiten verlaufen hier über kreuz, weil die TPTP-Plug-Ins nach ihren Projekten und nicht nach der hierarchischen Ordnung sortiert sind.

Die einzelnen Web-TEST-Plug-Ins der Abbildung 5.2 erfüllen folgenden Aufgaben:

Web-TEST-Lib-Plug-In (org.eclipse.tptp.test.tools.web.lib)

Das Web-TEST-Lib-Plug-In stellt Dritt-Bibliotheken (benötigte Bibliotheken die weder von Eclipse noch von TPTP bereit gestellt werden) für alle darüber liegenden Web-TEST-Plug-Ins zur Verfügung. Unter anderem werden die Bibliotheken für Htmlunit [36], für einen Log4j-Adapter [37] und für einen speziellen Base64-Encoder von Ostermiller-Utils [38] zur Verfügung gestellt.

Web-TEST-Models-Plug-In (org.eclipse.tptp.test.tools.web.models)

Das Web-Test-Models-Plug-In stellt das Web-TEST-Datenmodell zur Verfügung. Alle weiteren Plug-Ins verwenden dieses Datenmodell, um Web-TEST spezifische Daten zu verwalten. Das Web-TEST-Datenmodell wird im Kapitel 5.3 „Daten und Datenmodelle in Web-TEST“ detailliert erklärt.

Web-TEST-Core-Plug-In (org.eclipse.tptp.test.tools.web.core)

Dieses Plug-In stellt Aktionen und Dienste für die darüber liegenden Plug-Ins zur Verfügung. So ist etwa die Geschäftslogik hinter den verschiedenen Wizards in diesem Plug-In implementiert. Die Wizards selbst sind jedoch im Web-TEST-UI-Plug-In enthalten.

Web-TEST-Runner-Plug-In (org.eclipse.tptp.test.tools.web.runner)

Dieses Plug-In stellt die nötigen Dienste für die Kontrolle der Assertions während der Testausführung bereit. Hier ist also die Logik umgesetzt, die die Assertions ausführt und die in den Assertions gespeicherten Werte mit den bei der Testausführung gesammelten Werten vergleicht.

Web-TEST-UI-Plug-In (org.eclipse.tptp.test.tools.web.ui)

Das Web-TEST-UI-Plug-In dient zur Umsetzung aller Benutzeroberflächenobjekte. In diesem Plug-In befindet sich unter anderem der Web-TEST-Test- und Assertion-Editor, alle Wizards und die Editor-Aktionen.

Web-TEST-Recorder-Plug-In (org.eclipse.tptp.test.tools.web.recorder)

Das Web-TEST-Recorder-Plug-In bietet den Test-Generator-Dienst an. Dieser Dienst erzeugt aus den aufgenommenen Daten automatisch eine Web-TEST-Testressource.

Web-TEST-Business-Attribute-Criterion-Plug-In (org.eclipse.tptp.test.tools.web.criterion.ba)

Das Web-TEST-Business-Attribute-Criterion-Plug-In bietet alle Dienste rund um Business-Attribute-Kriterien an. Unter anderem ist auch der BA-Assertion-Generation-Wizard in diesem Plug-In realisiert. Die Dienste rund um das Business-Attribute-Kriterium wurden in einem eigenen Plug-In zusammengefasst, um ein Beispiel für die Erweiterbarkeit von Web-TEST zu bieten. Web-Test funktioniert auch ohne dieses Plug-In, wobei jedoch der wichtigste Kriterientyp fehlt. Ein Web-TEST-Kunde kann dieses Plug-In als Vorlage zur Entwicklung von eigenen Kriterientypen verwenden.

In den folgenden Kapiteln werden die Schnittstellen und Datenmodelle von Web-TEST beschrieben, um die Erweiterbarkeit zu demonstrieren und um Web-TEST-Kunden eine Dokumentation der Schnittstellen zu bieten. Dabei werden sowohl die Schnittstellen zwischen den TPTP-Plug-Ins und den Web-TEST-Plug-Ins, als auch die Schnittstellen zwischen Web-TEST und kundenspezifischen Erweiterungen erläutert:

Zuerst werden die zu verwendenden Datenmodelle im Kapitel 5.3 „Daten und Datenmodelle in Web-TEST“ erklärt.
Danach werden die von Web-TEST verwendeten TPTP-Erweiterungspunkte im Kapitel 5.4 „Die verwendeten TPTP-Erweiterungspunkte“ beschrieben.
Schließlich werden im Kapitel 5.5 „Die angebotenen Erweiterungspunkte“ alle Erweiterungspunkte der Web-TEST-Plug-Ins besprochen.

5.3 Daten und Datenmodelle in Web-TEST

Web-TEST verwendet die TPTP-Datenmodelle für Testdefinitionen und Testverhalten. Weiters verwendet Web-TEST ein eigenes Datenmodell webtestData für die Speicherung von Assertions und dynamischen Request-Parametern. Wie zuvor schon erwähnt darf Web-TEST seine Daten weder direkt in ein eigenes Dokument speichern noch darf das TPTP-Datenmodell erweitert werden. Aus diesem Grund wird aus dem webtestData-Datenmodell eine XML-Ressource erzeugt, die in einem zweiten Schritt in eine Zeichenkette konvertiert wird. Diese Zeichenkette kann dann als Wert eines generischen Elements des TPTP-Testdefinitionsmodells abgespeichert werden. Somit wird erreicht, dass alle Web-TEST-Daten im übergeordneten TPTP-Datenmodell abgespeichert werden, ohne dass das TPTP-Datenmodell geändert wird. Eine genauere Beschreibung dieses Vorgangs kann unter 5.5.1 „Die Erweiterungspunkte des Web-TEST-Models-Plug-In“ gefunden werden.

Im Folgenden wird gezeigt, wie Web-TEST die Test- und Assertiondaten mit Hilfe der TPTP-Datenmodelle und des Web-Test-Datenmodells webtestData verwalten kann.

5.3.1 Beispiel der Verwendung des Test- und Behavior-Modell in Web-TEST

Dieses Kapitel beschreibt, wie Web-TEST seine Daten in das TPTP-Test-Modell und im TPTP-Behavior-Modell abbildet. Zur Veranschaulichung wird hier ein Test mit folgenden Eigenschaften verwendet:

Eine Testsuite mit dem Namen „ShowModel_WebTEST“
Die Testsuite enthält vier Requests an den UnRisk-FACTORY-Webserver (www.unrisk.com):

1. Anzeigen der Login-Seite - Name: „1 GET UnRisk-FACTORY“

2. Einloggen - Name: „2 POST Admin Overview“

3. Anzeigen der Benuzter-Objekte - Name: „3 GET Users“

4. Ausloggen - Name: „4 GET UnRisk-FACTORY“

Das Testverhalten der Requests und der Testsuite wurde nicht verändert und entspricht der aufgezeichneten Reihenfolge und den aufgezeichneten Parametern.

Die folgenden Abbildungen - Abbildung 5.3, Abbildung 5.4 und Abbildung 5.5 - zeigen den Aufbau dieses Web-TEST-Tests, wie er in der Testressource nach der Aufnahme abgespeichert ist.

Abbildung 5.3 zeigt dabei die vollständige Datenstruktur als grafische Darstellung der XML-Testressource. Abbildung 5.4 und Abbildung 5.5 zeigen hingegen nur Ausschnitte aus Abbildung 5.3 mit Hilfe eines UML-Instanzdiagramms. In Abbildung 5.4 wird das Verhalten der Testsuite detaillierter erläutert und in Abbildung 5.5 wird das Verhalten der einzelnen Testfälle dargestellt.

Legende mit Linie (2): ID des verwendeten Testtyps

Interaction-Fragment referenziert Testcase-Behavior

Legende mit Linie (2): Testcases

Abbildung 5.3: Datenstruktur des Web-TEST-Tests „ShowModel_WebTEST“

In Abbildung 5.3 ist erkennbar, dass die Testsuite unter anderem aus einem „behavior“- und vier „testCase“-Elementen besteht, wobei das „behavior“-Element über die Kette „interaction“ / „interactionFragments“ / „interactionOperands“ weitere vier „interactionFragments“-Elemente enthält. Diese enthalten das Attribut „otherBehavior“. Das Element „otherBehavior“ ist eine Referenz auf das „behavior“-Element der einzelnen Testfälle - siehe den roten Kasten „Interaction-Fragment referenziert Testcase-Behavior“ in Abbildung 5.3.

In den folgenden UML-Instanzdiagrammen werden Kompositionen als Beziehungen und Aggregationen als Instanzvariablen beschrieben. Als Klassennamen werden die in den TPTP-Datenmodellen verwendeten Typbezeichnungen verwendet. Die Namen der UML-Instanzen entsprechen den Namen der XML-Elemente der in Abbildung 5.3 dargestellten Testressource.

Abbildung 5.4: Instanzmodell - Testsuite Behavior-Modell

Abbildung 5.4 zeigt nochmals die Definition des Testverhaltens der Testsuite (TPFTestSuite) „ShowModel_WebTEST“. Die Testsuite enthält das Testverhalten (TPFBehavior) „Test_Suite_behaviour“. Dieses enthält wiederum eine Interaktion (BVRInteraktion).

Die Interaktion wird ihrerseits durch die Lebenslinie (BVRLifeline) „TestSuite_LifeLine“ und durch ein Kombiniertes-Interaktionsfragment (BVRCombinedFragment) „Loop 1“ zusammengestellt. Das Kombinierte-Interaktionsfragment enthält einen Interaktionsoperator „loop“. Dadurch wird das Kombinierte-Interaktionsfragment „Loop 1“ als Schleife erkannt werden. Weiters enthält das Kombinierte-Interaktionsfragment noch einen Interaktionsoperanden (BVRInteractionOperand), der unter anderem die Schleifenbedingung enthält. Der Wert in der Abbildung ist „1“, deshalb wird die Schleife beim Ausführen des Tests nur einmal ausgeführt.

Der Interaktionsoperand enthält alle Sub-Interaktionsfragmente die im Rahmen der Schleife ausgeführt werden. Da das Testverhalten nach dem Aufnehmen nicht geändert wurde, enthält dieser Interaktionsoperand vier Interaktionsfragmente. Eines für jeden der vier aufgezeichneten Requests.

Jedes dieser Interaktionsfragmente verweist selbst wieder auf das Testverhalten eines Requests. Dieses Testverhalten wird im Request (im Testfall) selbst definiert und legt fest wie der Request ausgeführt wird. Die Verknüpfung von der Testsuite zu den Testverhalten der einzelnen Requests funktioniert über das Feld „otherBehavior“. In Abbildung 5.4 wird dieses Feld durch einen roten Rahmen hervorgehoben.

Abbildung 5.5: Instanzmodell - Testfälle und deren Behavior-Modell

Die Definition der einzelnen Testfälle (TPFTestCase) ist, wie Abbildung 5.5 zeigt, auch Teil der Testsuite „ShowModel_WebTEST“. Jeder Testfall enthält sein eigenes Testverhalten. Beispielsweise enthält der Testfall „2 POST Admin Overview“ das Testverhalten „2 POST Admin Overview_behavior“.

Das Testverhalten „2 POST Admin Overview_behavior“ enthält ebenfalls eine Interaktion, die aus einer Lebenslinie und einem Interaktionsfragment besteht. Das Interaktionsfragment referenziert mit Hilfe der Instanzvariable „lifeline“ die Lebenslinie der Testsuite - die „TestSuite_LifeLine“. Damit wird beschrieben, dass das Verhalten der Testfälle im Kontext der Lebenslinie der Testsuite ausgeführt wird.

Das Interaktionsfragment der Testfälle enthält außerdem alle Testfallparameter (BVRProperty). Die Testfallparameter sind alle verwendeten Request- und Response-Parameter. Beispielsweise wird unter dem Namen „DESC_ATT/Host“ der Host „www.unrisk.com“ abgespeichert. Auch der gesamte Response-Inhalt wird als Testfallparameter unter dem Namen „REF_RESP_ATT/Body“ abgespeichert. In der Abbildung 5.5 werden die Testfallparameter und ihre Werte rechts unten dargestellt. Beispielsweise wird der Parameter „REF_RESP_ATT/Body“ mit dem Wert „<!DOCTYPE html PUBLIC " …“ angezeigt. Dieser Parameter enthält also die HTML-Antwortseite, die bei der Testaufzeichnung aufgenommen wurde.

Schließlich enthält das Interaktionsfragment noch eine Nachricht (BVRMessage). Diese gibt an, wie die Kommunikation erfolgen soll. Beim Web-TEST-Test wird hier angegeben, ob es sich um einen GET- oder POST-Request handelt.

Mit Hilfe dieses Schemas kann die Testdefinition eines Web-TEST-Tests im TPTP-Testmodell abgebildet werden. Als nächstes ist zu klären, wie Assertions in das TPTP-Testmodell aufgenommen werden können.

5.3.2 Das webtestData-Datenmodell

Abbildung 5.6: Das „webtestData“ Datenmodell

Abbildung 5.6 zeigt den Aufbau der webtestData-Datenstruktur. Diese erlaubt es Web-TEST die zusätzlichen Daten, wie Assertions, zu speichern. Dabei wird die Speicherung von folgenden Elementen unterstützt:

Test-Value-Selector: dieser Datentyp erlaubt das Speichern von Value-Selector-Elementen, die über die Assertion-Editor-Seite „Value Selector“, die in Abbildung 3.36 dargestellt ist, verwaltet werden können.

Test-Filled-Parameter: dieser Datentyp erlaubt das Speichern von dynamischen Request-Parametern. Diese Parameter können über die Assertion-Editor-Seite „Parameter“ wie in Abbildung 3.37 dargestellt verwaltet werden.

XPath-Criterion: dieser Datentyp erlaubt das Speichern von XPath-Kriterien. Diese Kriterien werden über die Assertion-Editor-Seite „XPath Criterion“ wie in Abbildung 3.31 dargestellt verwaltet.

Html-Criterion: dieser Datentyp erlaubt das Speichern von Text-Kriterien. Diese Kriterien werden über die Assertion-Editor-Seite „Text Criterion“ wie in Abbildung 3.30 dargestellt verwaltet.

Business-Attribute-Criterion: dieser Datentyp erlaubt das Speichern von Business-Attribute-Kriterien. Diese Kriterien werden über die Assertion-Editor-Seite „Business Att. Criterion“ wie in Abbildung 3.32 dargestellt verwaltet.

In Abbildung 5.6 ist auch erkennbar, dass die einzelnen Elemente beliebig oft vorkommen können (markiert durch den Qualifier [0..*]).

Abbildung 5.7: Die Daten von „webtestData“ die im gezeigten Anwendungsfall erstellt wurden

Abbildung 5.7 zeigt die Datenstruktur webtestData, wie sie am Ende des gezeigten Anwendungsfalls aus Kapitel 3.3 aussieht. Man erkennt, dass die Datenstruktur vier Value-Selector-Elemente, zwei dynamische Request-Parameter, sechs verschiedene Kriterien und fünf damit zusammengestellte Assertions enthält.

Im Folgenden werden die verschiedenen Elemente erläutert und ihre Bedeutung erklärt. Weiters wird versucht, mit Hilfe der Daten des Anwendungsfalls dem Leser zu vermitteln, wie die Daten der Benutzeroberfläche in der Datenstruktur abgespeichert werden.

Der Datentyp Test-Value-Selctor

Abbildung 5.8: Der Datentyp Test-Value-Selector

Wie in Abbildung 5.8 dargestellt, enthält der Datentyp Test-Value-Selector folgende Elemente und Attribute:

Element- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
RefTestCaseRef	Enthält die Referenz auf einen Request. Hier wird keine IDREF verwendet, weil die Testfälle (Requests) in der übergeordneten TPTP-Datenstruktur festgelegt werden und deshalb nicht im selben XML-Dokument sind.
Type	Unterscheidet zwischen „RESPONSE“- und „REQUEST“-Value-Selector-Elementen. Eine Beschreibung dieser beiden Typen von Value-Selector-Elementen wurde bereits in Kapitel 3.3.5 gemacht.
XPath	Enthält den XPath-Ausdruck für einen Response-Value-Selector.
ParameterName	Enthält den Namen eines GET- oder POST-Request-Parameters eines Request-Value-Selectors. Die möglichen Parameternamen werden dabei aus dem unter RefTestCaseRef referenzierten Requests abgeleitet.

Tabelle 5‑1: Elemente und Attribute des Datentyps Test-Value-Selector

Abbildung 5.9: Daten eines Test-Value-Selector-Elements

Abbildung 5.9 zeigt die Daten des Test-Value-Selectors „Value Selector 0“, der im Rahmen des gezeigten Anwendungsfalls erstellt wurde. Es handelt sich hierbei um einen Response-Value-Selector. Deshalb enthält das Feld Type den Wert „RESPONSE“, das Feld XPath enthält einen XPath-Ausdruck und das Feld ParameterName ist leer. Im Fall eines Request-Value-Selectors wäre das Feld XPath leer und dafür würde das Feld Parametername einen Wert enthalten.

Der Datentyp Test-Filled-Parameter

Abbildung 5.10: Der Datentyp Test-Filled-Parameter

Wie in Abbildung 5.10 dargestellt, enthält der Datentyp Test-Filled-Parameter folgende Elemente und Attribute:

Element- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
DefaultValue	Ein Standardwert, der als Wert des Parameters herangezogen wird, falls während der Testausführung der assoziierte Response-Value-Selector noch keinen Wert geliefert hat.
ResponseValue-SelectorRef	Enthält eine Referenz auf einen Response-Value-Selector.
RequestValue-SelectorRef	Enthält eine Referenz auf einen Request-Value-Selector.
Response-TestCaseRef	Enthält eine Referenz auf einen Request (ein Request ist in Web-TEST ein Äquivalent zu einem Testfall). Nach der Ausführung dieses Requests wird der assoziierte Response-Value-Selector auf den gelieferten Response angewendet, um den Parameterwert zu ermitteln. Ein Test-Filled-Parameter-Element kann beliebig viele ResponseTestCaseRef-Elemente enthalten.
Request-TestCaseRef	Enthält eine Referenz auf einen Request. Bei der Ausführung dieses Requests wird der aktuelle Wert des dynamischen Request-Parameters als Wert des durch den Request-Value-Selector ausgewählten Parameters verwendet. Ein Test-Filled-Parameter-Element kann beliebig viele RequestTestCaseRef-Elemente enthalten.

Tabelle 5‑2: Elemente und Attribute des Datentyps Test-Filled-Parameter

Abbildung 5.11: Daten eines Test-Filled-Parameter-Elements

Abbildung 5.11 zeigt die Daten des dynamischen Request-Parameters „Parameter 0“, der im Rahmen des Anwendungsfalls erstellt wurde. Der DefaultValue dieses Parameters ist leer. Es wird jedoch sowohl ein Response-Value-Selector, als auch ein Request-Value-Selector mit dem Parameter verknüpft. Weiters ist erkennbar, dass sowohl ein Request zum Extrahieren des Wertes referenziert wird (ResponseTestCaseRef), wie auch ein Request zum Verwenden des Parameterwerts (RequestTestCaseRef).

Der Datentyp XPath-Criterion und der Datentyp Criterion

Abbildung 5.12: Der Datentyp XPath-Criterion

Wie Abbildung 5.12 darstellt, kann der Datentyp XPath-Criterion folgende Elemente und Attribute enthalten:

Feld- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
Description	Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung des Titels ‚Administration’“
XPathExpresssion	Enthält einen XPath-Ausdruck, der bei der Ausführung des Tests auf die assoziierten Requests angewendet wird. Das Ergebnis wird mit den im XPath-Criterion-Element gespeicherten Criterion-Elementen verglichen.
Criterion	Ein Criterion enthält den erwarteten Wert und die zu verwendende Vergleichsbedingung. Ein XPath-Criterion-Element kann beliebig viele Criterion-Elemente enthalten.

Tabelle 5‑3: Elemente und Attribute des Datentyps XPath-Criterion

In Abbildung 5.12 wird weiters dargestellt, wie ein Criterion-Element aufgebaut ist. In der folgenden Tabelle werden die Felder und Attribute des Criterion-Datentyps näher beschrieben:

Feld- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
Description	Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung des Seitentitels ‚Administration’.“
Datatyp	Enthält den vollständigen Klassennamen eines Java-Datentyps. Zurzeit werden von Web-TEST folgende Datentypen unterstützt: java.lang.String, java.lang.Integer und java.lang.Double.
Operation	Enthält den Vergleichsoperator. Mit diesem Operator werden der gefundene Wert und der im Kriterium gespeichert Wert verglichen. Zurzeit werden von Web-TEST folgende Vergleichsoperatoren unterstützt: Equals, Not Equal, Less Than, Greater Than, Contains und Doesn’t Contain.
Value	Enthält den erwarteten Wert als Zeichenkette. Während der Testausführung muss der Wert wieder in den unter Datatype gespeicherten Datentyp konvertiert werden.
UseRegEx	Gibt an, ob der in Value gespeicherte Wert als regulärer Ausdruck interpretiert werden soll. „True“ oder „False“.
UseOnlyText	Gibt an, ob der erwartete Wert im gesamten HTML-Text des Responses oder in dem um die HTML-Tags bereinigten Text gesucht werden soll. „True“ oder „False“.

Tabelle 5‑4: Elemente und Attribute des Datentyps Criterion

Abbildung 5.13: Daten eines XPath-Criterion-Elements

Abbildung 5.13 zeigt die Daten des XPath-Criterions „DOM View XPath Criterion 0“, das im Rahmen des Anwendungsfalls erstellt wurde. Das Element XPathExpression gibt den XPath-Ausdruck an, der verwendet wird, um einen Wert im Response auszuwählen. Weiters enthält das XPath-Criterion noch ein Criterion-Element, das einen „java.lang.String“ mit dem Wert „Administration“ mit der Operation „Equals“ mit dem durch den XPath-Ausdruck gefundenen Wert vergleicht.

Der Datentyp Html-Criterion

Abbildung 5.14: Der Datentyp Html-Criterion

Wie Abbildung 5.14 darstellt, enthält der Datentyp Html-Criterion folgende Elemente und Attribute:

Feld- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
Description	Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung des Titels ‚Administration’“
Criterion	Ein Criterion enthält den erwarteten Wert und die zu verwendende Vergleichsbedingung. Ein Html-Criterion-Element kann wieder beliebig viele Criterion-Elemente enthalten.

Tabelle 5‑5: Elemente und Attribute des Datentyps Html-Criterion

Abbildung 5.15: Daten eines Html-Criterion-Elements

Abbildung 5.15 zeigt die Daten des Html-Criterions „Browser View Text Criterion 0“, das im Rahmen des Anwendungsfalls erstellt wurde. Das Html-Criterion enthält wieder ein Criterion-Element, das den im Response zu suchenden Wert und den Vergleichoperator enthält.

Der Datentyp Business-Attribute-Criterion

Abbildung 5.16: Der Datentyp Business-Attribute-Criterion

Wie Abbildung 5.16 darstellt, enthält der Datentyp Business-Attribute-Criterion folgende Elemente und Attribute:

Feld- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
Description	Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung von Input-Feldern“
AbsElementXPath	Ein XPath-Ausdruck, der den Pfad zu den ausgewählten Elementen im Response angibt. Um alle Input-Felder auszuwählen, kann beispielsweise „//input“ verwendet werden.
RelNameXPath	Ein XPath-Ausdruck, der relativ zum ausgewählten Element ist. Mit Hilfe dieses XPath-Ausdrucks wird der Name des Elements extrahiert. Um den Namen von Input-Feldern auszuwählen, kann beispielsweise „@name“ verwendet werden.
RelValueXPath	Ein XPath-Ausdruck, der relativ zum ausgewählten Element ist. Mit Hilfe dieses XPath-Ausdrucks wird der Wert des Elements extrahiert. Um den Wert von Input-Feldern auszuwählen, kann beispielsweise „@value“ verwendet werden.
TestBASequence	Gibt an, ob die Reihenfolge der Kriterien überprüft werden muss. „True“ oder „False“.
Criterion	Ein Criterion enthält den erwarteten Wert und die zu verwendende Vergleichsbedingung. Ein Business-Attribute-Criterion-Element kann wieder beliebig viele Criterion-Elemente enthalten.

Tabelle 5‑6: Elemente und Attribute des Datentyps Business-Attribute-Criterion

Abbildung 5.17: Daten eines Business-Attriubte-Criterions

Abbildung 5.15 zeigt die Daten des Business-Attribute-Criterions „BA View BA Criterion 0“, das auch im Rahmen des Anwendungsfalls erstellt wurde. Das Element AbsElementXPath enthält den XPath-Ausdruck „//table[@class=“details“]//tr“. Dadurch werden alle Zeilen einer bestimmten Tabelle als Elemente ausgewählt. Mit Hilfe des Elements RelNameXPath „th“ wird der Name des Elements auf den Wert der Header-Zelle gesetzt. Weiters setzt das Elemente RelValueXPath „td“ den Wert des Elements auf den Inhalt der ersten normalen Zelle der Tabellen-Zeile. Das Business-Attribute-Criterion enthält zusätzlich mehrere Criterion-Elemente. Jedes dieser Criterion-Elemente entspricht einem Element, das im Response enthalten sein muss. Dabei wird zuerst innerhalb der gefundenen Elemente nach dem entsprechenden Namen gesucht und dann der Wert mit Hilfe des Vergleichsoperators überprüft. In dem in der Abbildung gezeigten Criterion-Element wird etwa die Tabellen-Zeile mit der Header-Zelle „ISIN“ gesucht und der Wert der ersten normalen Zelle mit der Zeichenkette „Test WebTEST1“ und dem Operator „Equals“ verglichen.

Der Datentyp Assertion

Abbildung 5.18: Der Datentyp Assertion

Wie Abbildung 5.18 darstellt, kann der Datentyp Assertion folgende Elemente und Attribute enthalten:

Feld- bzw. Attributname	Beschreibung
Id	Eine automatisch generierte eindeutige Identifikationsnummer.
Name	Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.
Description	Eine Beschreibung der Assertion, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Bedingung, die überprüft, ob die zuvor gespeicherten Daten einer Swapcurve richtig angezeigt werden.“
RefTestCaseRef	Die ID eines Referenz-Testfalles. Hier wird keine IDREF verwendet, weil die Testfälle in der übergeordneten TPTP-Datenstruktur festgelegt werden und deshalb nicht im selben XML-Dokument sind.
TestCaseRef	Die ID eines Testfalls (Requests), nach dem die Assertion ausgeführt werden soll. Hier wird wieder keine IDREF verwendet, weil die Testfälle in der übergeordneten TPTP-Datenstruktur festgelegt werden. Eine Assertion kann beliebig viele TestCaseRef-Elemente enthalten.
XPathCriterionRef	Eine Referenz (eine IDREF) auf ein zu überprüfendes XPath-Criterion-Element.
HtmlCriterionRef	Eine Referenz (eine IDREF) auf ein zu überprüfendes HTML-Criteron-Element.
BusinessAttribute-CrtierionRef	Eine Referenz (eine IDREF) auf ein zu überprüfendes Business-Attribute-Criterion-Element.

Tabelle 5‑7: Elemente und Attribute des Datentyps Business-Attribute-Criterion

Abbildung 5.19: Daten einer Assertion

Abbildung 5.19 zeigt die Daten der Assertion „Auto Assertion 0“, die ebenfalls im Rahmen des Anwendungsfalls erstellt wurde. Die Assertion enthält unter anderem eine Referenz auf einen Testfall, bei dem diese Assertion ausgeführt werden muss (TestCaseRef). Weiters werden noch zwei Business-Attribute-Criterion-Elemente referenziert, die im Rahmen dieser Assertion überprüft werden.

5.4 Die verwendeten TPTP-Erweiterungspunkte

Im Folgenden werden die von Web-TEST verwendeten Erweiterungspunkte, des TPTP-Frameworks erläutert. Die folgenden Abbildungen, Abbildung 5.20, Abbildung 5.24 und Abbildung 5.26, zeigen alle von Web-TEST verwendeten TPTP-Erweiterungspunkte aufgeteilt auf die Web-TEST-Plug-Ins.

5.4.1 Die verwendeten Erweiterungspunkte im Web-TEST-UI-Plug-In

Abbildung 5.20: Die in Web-TEST-UI erweiterten TPTP-Erweiterungspunkte

Abbildung 5.20 zeigt die Erweiterungspunkte, die im Web-TEST-UI-Plug-In verwendet werden. Es folgt eine Auflistung mit einer kurzen Beschreibung der einfachen Erweiterungen und eigene Unterkapitel für die bedeutenderen Erweiterungen.

typeValidators: Dieser Erweiterungspunkt ermöglicht es, bei der Testausführung zu überprüfen, ob der gewählte Testtyp ausgeführt werden darf.

launchconfigRunHandler: Dieser Erweiterungspunkt ermöglicht es, Aktionen vor und nach der Testausführung durchzuführen.

propertySourceExtension: Dieser Erweiterungspunkt ermöglicht es, spezielle Daten für die Eclipse-Property-View zur Verfügung zu stellen.

Der Erweiterungspunkt Testtyp-Beschreibung (typeDescriptions)

Abbildung 5.21: Die Erweiterung des Erweiterungspunkts Testtyp-Beschreibung

In Abbildung 5.21 wird die in Web-TEST verwendete Umsetzung des Erweiterungspunkts Testtyp-Beschreibung dargestellt. Der Erweiterungspunkt dient dazu, neue Testtypen zu beschreiben. Dabei können neben einer ID auch ein Name, eine Beschreibung und ein Icon für einen Testtyp festgelegt werden. Weiters wird die Dateiendung der Testressource definiert, die diesem Testtyp zugeteilt ist. Eine entsprechende Testressource wird dann mit dem festgelegten Icon im Test-Navigator angezeigt. In Abbildung 5.21 wird im Feld type die ID des Testtyps mit „org.eclipse.hyades.test.web.junit.testSuite“ festgelegt. Diese ID findet sich auch in der Testressource wieder, wie in Abbildung 5.3 gezeigt wurde. Dadurch wird eindeutig bestimmt, welcher Testtyp in der Testressource enthalten ist.

Der Erweiterungspunkt Test-Editor-Extension (editorExtension)

Abbildung 5.22: Die Erweiterung des Erweiterungspunkts Test-Editor-Beschreibung

Abbildung 5.22 zeigt die beiden Realisierungen des Erweiterungspunkts Test-Editor-Extension, die in Web-TEST verwendet werden. Die erste Realisierung, mit dem Namen „Web TEST Http Test Editor“, stellt einen Multi-Page-Editor zum Editieren der Testdefinition eines Web-TEST-Tests zur Verfügung. Die Oberfläche des Editors ist in Abbildung 3.15 dargestellt. Die Implementierung des Editors findet sich in der Klasse org.eclipse.tptp.test.tools.web.ui.test.editor.WebTestEditorExtension. Die zweite Erweiterung, mit dem Namen „Web TEST Assertion Editor“, stellt einen Multi-Page-Editor zum Verwalten von Assertions zur Verfügung. Die Oberfläche dieses Editors ist in Abbildung 3.29 zu sehen. Die Implementierung des Editors ist in der Klasse org.eclipse.tptp.test.tools.web.ui.ass.editor.WebAssertionEditorExtension.

Der Erweiterungspunkt Testcode-Generierungs-Wizard (generateWizard)

Abbildung 5.23: Die Erweiterung des Erweiterungspunkts Testcode-Generierungs-Wizard

Abbildung 5.23 zeigt die Umsetzung des Erweiterungspunkts Testcode-Generierungs-Wizard. Dieser Erweiterungspunkt erlaubt es, einen Wizard zu definieren der die Testdefinition in eine ausführbare Form umwandelt. In Web-TEST wird aus der Testdefinition Java-Code erzeugt. Dieser Wizard ist in der Klasse org.eclipse.tptp.test.tools.web.ui.junit.wizard.WebHttpGenerateWizard implementiert.

5.4.2 Die verwendeten Erweiterungspunkte im Web-TEST-Core-Plug-In

Abbildung 5.24: Die in Web-TEST-Core erweiterten TPTP-Erweiterungspunkte

Abbildung 5.24 zeigt alle TPTP-Erweiterungspunkte, die im Web-TEST-Core-Plug-In erweitert werden. Es folgt eine kurze Beschreibung der einfachen Erweiterungen:

ExecutableObjectAdapter: Dieser Erweiterungspunkt dient dazu, den Testausführungsprozess zur Laufzeit zu konfigurieren.

ExecutionDeploymentAdapter: Dieser Erweiterungspunkt dient dazu, dem Testausführungsprozess alle nötigen Daten zur Testausführung zur Verfügung zu stellen. Dabei werden die Datentransport-Dienste des Agent-Controllers verwendet.

ExecutionEnvironmentAdapter: Dieser Erweiterungspunkt dient zur Konfiguration der Ausführungsumgebung. Zum Beispiel wird der Testausführung mitgeteilt, wo der Agent-Controller zu finden ist.

launchconfigLaunchableType: Dieser Erweiterungspunkt dient zum Definieren der Testtypen, die über die Eclipse-Launch-Option „Test“ ausgeführt werden können.

launchconfigValidator: Dieser Erweiterungspunkt dient dazu, zu überprüfen, ob eine bestimmte Testressource wirklich über die Eclipse-Launch-Option „Test“ ausgeführt werden kann.

Da der Erweiterungspunkt RegisteredExecutionComponentImpl eine zentrale Rolle in der Ausführung eines Tests spielt, wird dieser in einem eigenen Unterkapitel beschrieben.

Der Erweiterungspunkt Test-Ausführungs-Komponente (RegisteredExecutionComponentImpl)

Mit Hilfe des Erweiterungspunkts Test-Ausführungs-Komponente können einem Testtyp Ausführungskomponenten zugeteilt werden. Nur mit Hilfe dieser Ausführungskomponenten kann ein Test dieses Testtyps über den Agent-Controller ausgeführt werden. Dabei können die Ausführungsumgebung (Environment), der Ausführungsprozess (Executor), der für das Monitoring verwendete Agent und das Ausführungsobjekt (Executable-Object) eingestellt werden.

Da jede der Komponenten über den Agent-Controller auf einer entfernten Maschine ausgeführt werden kann, muss auch jede Teilkomponente eine Stub- (lokaler Stellvertreter) und eine Skeleton-Implementierung (entfernter Stellvertreter) bereitstellen.

Abbildung 5.25: : Die Erweiterung des Erweiterungspunkts Test-Ausführungs-Komponente

In Abbildung 5.25 werden die Einstellung der in Web-TEST verwendeten Ausführungskomponenten dargestellt. Die Komponenten werden als eigene RegisteredExecutionComponentImpl-Elemente hinzugefügt. Das Feld type identifiziert die Art der Subkomponente, das Feld implClass gibt die Realisierung an, und mit Hilfe des Unterelements SupportedTestType kann angegeben werden, für welchen Testtyp diese Einstellungen verwendet werden. In Web-TEST werden dabei folgende, in Abbildung 5.25 dargestellte, Komponenten festgelegt:

Teilkomponente	Beschreibung
Environment	Diese Komponente der Ausführung hat das Wissen über die Ausführungsumgebung. Alle nötigen Umgebungsvariablen können vom Executor über diese Komponente abgefragt werden. Implementiert wird diese Komponente, für den Web-TEST-Testtyp „org.eclipse.hyades.test.web.junit.testSuite“, von der Klasse org.eclipse.hyades.execution.core.impl.ExecutionEnvironmentImpl.
Executor	Diese Komponente der Ausführung stellt Dienste bereit, um ein Executable-Object zu starten, zu steuern und zu beenden. Implementiert wird diese Teilkomponente von der Klasse org.eclipse.hyades.execution.core.impl.ProcessExecutorImpl.
Debug-Executor	Ermöglicht das Ausführen von Executable-Objects im Eclipse-Debug-Modus. Gegenüber der Executor-Teilkomponente wird eine andere Stub-Implementierung speziell für den Debug-Modus verwendet: org.eclipse.hyades.execution.harness.DebugExecutorStub.
Agent	Stellt eine Schnittstelle zum Überwachen der Ausführung des Executable-Objects zur Verfügung. Zu erwähnen ist, dass die meisten Funktionen lokal im Stub-Teil umgesetzt sind und die eigentliche Agent-Implementierung kaum verwendet wird. Der Stub-Teil ist in der Klasse org.eclipse.hyades.execution.local.JavaTaskRemoteHyadesComponentStub realisiert und implementiert fast alle Methoden selbst, ohne auf die Agent-Implementierung in org.eclipse.hyades.execution.core.impl.JavaTaskRemoteHyadesComponentImpl zurückzugreifen.
Executable-Object	Ein Executable-Object ist eine Klasse die vom Executor in einer eigenen JVM ausgeführt werden kann. Das Executable-Object ist eine Hülle für den Quellcode eines Web-TEST-Tests. Dadurch kann der Test über den Agent-Controller ausgeführt werden. Realisiert wird diese Komponente der Ausführung in der Klasse org.eclipse.hyades.execution.core.impl.JavaProcessExecutableObjectImpl.

Tabelle 5‑8: Erweiterungspunkt Test-Ausführungs-Komponente

Für die Umsetzung des Erweiterungspunkts Test-Ausführungs-Komponente konnten in Web-TEST die Klassen des TPTP-URL-Tests herangezogen werden. Somit wird zwar der Erweiterungspunkt von Web-TEST erweitert, um bekannt zu geben, wie ein Web-TEST-Test ausgeführt wird, dabei wird jedoch auf die selben Implentierungsklassen zurückgegriffen wie auch im TPTP-URL-Test.

5.4.3 Die verwendeten Erweiterungspunkte im Web-TEST-Recorder-Plug-In

Abbildung 5.26: Der in Web-TEST-Core erweiterte TPTP-Erweiterungspunkt

Im Web-TEST-Recorder-Plug-In wird, wie in Abbildung 5.26 dargestellt, der Erweiterungspunkt Test-Generator umgesetzt. Diese Erweiterung generiert eine Web-TEST-Testressource aus den vom TPTP-Recorder aufgenommenen Daten. Die Testressource kann dann mit dem Test-Editor von Web-TEST verwaltet werden. Realisiert wird diese Funktion in der Klasse org.eclipse.tptp.test.tools.web.test.generation.WebTestgen.

5.5 Die angebotenen Erweiterungspunkte

Ein wesentlicher Aspekt von Web-TEST ist die Erweiterbarkeit und Anpassbarkeit durch Kunden. Dazu definiert auch Web-TEST Erweiterungspunkte, die von kundenspezifischen Erweiterungen verwendet werden können. In den folgenden Unterkapiteln werden die von Web-TEST bereitgestellten Erweiterungspunkte erläutert.

5.5.1 Die Erweiterungspunkte des Web-TEST-Models-Plug-Ins

Abbildung 5.27: Die Erweiterungen in Web-TEST-Models

Im Web-TEST-Models-Plug-In werden, wie Abbildung 5.27 zeigt, folgende drei Erweiterungspunkte angeboten:

Der Erweiterungspunkt Assertion-Speicher (assertion_storage)

Der Erweiterungspunkt Assertion-Speicher erlaubt es, eine Klasse zum Speichern und Laden der Web-TEST-Datenstruktur webtestData zu definieren. Weiters kann die Implementierung mit einer Priorität versehen werden, um eine zuvor verwendete Implementierung zu überschreiben. Die von Web-TEST-Models zur Verfügung gestellte Standardimplementierung speichert webtestData in der TPTP-Testressource. Das ist, wie zuvor bereits erwähnt, eine Anforderung des TPTP-Teams. Dabei wird das generische TPTP-Modell-Element instance verwendet. Dieses Element kann einen Wert (initialValue) als Zeichenkette speichern.

Abbildung 5.28: Speicherung von webtestData innerhalb der TPTP-Testressource

Abbildung 5.28 zeigt, dass webtestData als Wert des instance-Elements mit dem Namen „Web_TEST_Data“ abgespeichert wird. Der Wert dieses Elements ist jedoch selbst wieder ein XML-Dokument, das alle Daten von webtestData enthält. Das Speichern und Laden der webtestData-Datenstruktur ist also ein zweistufiger Prozess:

Lesen des Werts des instance-Elements „Web_TEST_Data“ der Testsuite.
Überführen des gelesenen Werts in ein XML-Dokument, damit ein strukturiertes Lesen und Bearbeiten möglich ist.

Diese Standardimplementierung des Erweiterungspunkts Assertion-Speicher hat die Priorität „0“ und kann mit einer höheren Priorität überschrieben werden.

Der Erweiterungspunkt Kriterium-Typ (criterion_type)

Diese Erweiterung dient dazu, neue Kriterientypen zu erstellen. Alle in Web-Test verwendeten Kriterientypen werden über diesen Erweiterungspunkt angeboten. Die Kriterientypen: Text-Kriterium und XPath-Kriterium werden vom Web-TEST-Models-Plug-In definiert, während Business-Attribute-Kriterium vom Web-TEST-Business-Attribute-Criterion-Plug-In definiert wird.

Abbildung 5.29: Definition des Kriterium-Typs Business-Attriubte-Kriterium

Abbildung 5.29 zeigt, wie das Business-Attribute-Kriterium definiert ist. Dabei muss eine eindeutige ID („org.eclipse.tptp.platform.models.criterion_type.ba_criterion“), ein Name für die Benutzeroberfläche („Business Attribute Criterion“), eine Factory-Klasse („org.eclipse.tptp.test.tools.web.criterion.ba.data.factory.impl.BACriterionFactoryImpl“) und eine Ordnungsnummer („3“) definiert werden. Die Factory-Klasse dient zum erzeugen einer Instanz des Kriteriums. Die Ordnungsnummer gibt an, in welcher Reihenfolge die verschiedenen Kriterientypen abgearbeitet werden. Wichtig ist, dass für jeden neuen Kriterium-Typ auch folgende zusätzliche Erweiterungspunkte implementiert werden müssen:

criterion_storage
criterion_type_engine
criterion_type_form

Der Erweiterungspunkt Kriterium-Speicher (criterion_storage)

Der Erweiterungspunkt Kriterium-Speicher ist dafür verantwortlich ein Kriterium in webtestData zu speichern. Im Gegensatz zum Assertion-Speicher muss sich der Kriterium-Speicher nicht mehr um die Integration in die TPTP-Testressource kümmern. Der Kriterium-Speicher ist lediglich dafür verantwortlich, dass ein Kriterium in die webtestData-Datenstruktur aufgenommen werden kann. Auch für diesen Erweiterungspunkt gibt es für alle in Web-TEST verwendeten Kriterientypen eine Implementierung: der Text-Kriterium-Speicher und der XPath-Kriterium-Speicher werden vom Web-TEST-Models-Plug-In definiert, während der Business-Attribute-Kriterium-Speicher vom Web-TEST-Business-Attribute-Criterion-Plug-In definiert wird.

Abbildung 5.30: Definition des Kriterium-Speichers für Business-Attriubte-Kriterien

Abbildung 5.30 zeigt, wie der Speicher des Business-Attribute-Kriteriums definiert ist. Dabei muss eine eindeutige ID („org.eclipse.tptp.models.web.common.storage.xml.ba_criterion“), ein Name für die Benutzeroberfläche („Default Business Attribute Storage“), der Name des Kriteriums („Business Attribute Criterion“), eine Speicher-Klasse („org.eclipse.tptp.test.tools.web.criterion.ba.store.XMLBACriterionStorage“) und eine Priorität („1“) definiert werden. Die Priorität wird wieder zum Überschreiben einer zuvor verwendeten Implementierung benötigt. Die Speicher-Klasse dient zum Speichern der Daten des Kriteriums in webtestData und zum Speichern der Referenzen auf das Kriterium innerhalb von Assertions. Dazu muss diese Klasse das in Abbildung 5.31 dargestellte Interface implementieren.

Abbildung 5.31: Die Schnittstelle org.eclipse.tptp.models.web.common.storage.ICriterionStorage

Die Methoden persist und load greifen dabei auf die in webtestData gespeichert Kriterien des angegebenen Typs zu, während die Methoden persistToAssertion und loadCritOfAssertion nur die Kriterien-Referenzen innerhalb von Assertions behandeln.

5.5.2 Der Erweiterungspunkt des Web-TEST-Core-Plug-Ins

Abbildung 5.32: Die Erweiterungen in Web-TEST-Core

Im Web-TEST-Core-Plug-In wird, wie Abbildung 5.32 zeigt, der Erweiterungspunkt criterion_type_engine definiert. Aufgrund der Erweiterbarkeit der Kriterientypen muss auch die Ausführung der Assertions erweiterbar sein. Wenn eine Assertion während einer Testausführung durchgespielt wird, dann hängt es von den verwendeten Kriterientypen ab, welche Überprüfungen gemacht werden. Dazu muss mit jedem Kriterium-Typ auch eine criterion_type_engine verknüpft sein. Deshalb gibt es für alle in Web-TEST verwendeten Kriterientypen, eine Implementierung: die Text-Kriterium-Engine und die XPath-Kriterium-Engine werden vom Web-TEST-Runner-Plug-In definiert, während die Business-Attribute-Kriterium-Engine vom Web-TEST-Business-Attribute-Criterion-Plug-In definiert wird.

Abbildung 5.33: Definition der Kriterium-Typ-Engine für das Business-Attriubte-Kriterium

Abbildung 5.33 zeigt, wie die Engine für das Business-Attribute-Kriterium definiert ist. Dabei muss eine eindeutige ID („org.eclipse.hyades.test.tools.core.criterion_type_engine.ba_criterion“), ein Name für die Benutzeroberfläche („Default Business Attribute Criterion Engine Provider“), der Name des Kriteriums („Business Attribute Criterion“), eine Engine-Klasse („org.eclipse.tptp.test.tools.web.criterion.ba.engine.provider.BACriterionEngineClassProvider“) und eine Priorität („1“) definiert werden. Die Priorität wird wieder zum Überschreiben einer zuvor verwendeten Implementierung verwendet. Die Engine-Klasse dient zum Ausführen des Kriteriums im Rahmen einer Assertion.

5.5.3 Die Erweiterungspunkte des Web-TEST-UI-Plug-Ins

Abbildung 5.34: Die Erweiterungen in Web-TEST-UI

Im Web-TEST-UI-Plug-In werden, wie Abbildung 5.34 zeigt, folgende drei Erweiterungspunkte angeboten.

Der Erweiterungspunkt Response-From (response_form)

Der Erweiterungspunkt Response-Form erlaubt es, eine zusätzliche Seite des Multi-Page-Editors Web-TEST-Test-Editor zu definieren. Mit dieser Seite kann ein Response auf eine spezielle Weise anzeigt werden. Zurzeit gibt es in Web-TEST drei Implementierungen dieses Erweiterungspunkts: Response-HTML-Browser (siehe Abbildung 3.20) und Response-DOM-Browser (siehe Abbildung 3.23) im Web-TEST-UI-Plug-In und Response-BA-Browser (siehe Abbildung 3.25) im Web-Test-Business-Attribute-Criterion-Plug-In.

Der Erweiterungspunkt Assertion-Wizard (assertion_wizard)

Dieser Erweiterungspunkt dient dazu, aus den aufgezeichneten Responses automatisch Assertions zu erzeugen. In Web-TEST gibt es zurzeit eine Umsetzung dieses Wizards: der Business-Attribute-Assertion-Wizard (siehe Abbildung 3.28) im Web-Test-Business-Attribute-Criterion-Plug-In. Mit Hilfe dieses Wizards werden wie im Unterkapitel „Der BA-Assertion-Generation-Wizard“ unter Punkt 3.3.3 beschrieben automatisch BA-Assertions erzeugt.

Der Erweiterungspunkt Kriterientyp-Form (criterion_type_form)

Der Erweiterungspunkt Kriterientyp-Form erlaubt es, eine Seite des Multi-Page-Editors Web-TEST-Assertion-Editor zu definieren. Mit dieser Seite kann ein Kriterium des angegebenen Typs bearbeitet werden. Deshalb gibt es für alle in Web-TEST verwendeten Kriterientypen eine Implementierung: die Text-Kriterium-Form (siehe Abbildung 3.30) und die XPath-Kriterium-Form (siehe Abbildung 3.31) werden vom Web-TEST-UI-Plug-In definiert, während die Business-Attribute-Kriterium-Form (siehe Abbildung 3.32) vom Web-TEST-Business-Attribute-Criterion-Plug-In definiert wird.

6 Ausblick und Schlussfolgerung

Wie in den letzten Kapiteln dargestellt, bieten Web-TEST und TPTP eine exzellente Möglichkeit der Weiterentwicklung und Anpassung über das Eclipse-Konzept der Erweiterungspunkte. Diese Erweiterbarkeit wurde mit Hilfe des Web-TEST-Business-Attribute-Criterion-Plug-Ins gezeigt. Dabei wurde Web-TEST um eine neuen Kriterientyp erweitert.

Es sind bereits folgende weitere Kriterientypen geplant:

Response-Parameter-Kriterium: Dieser Kriterientyp soll es ermöglichen, Response-Parameter auf bestimmte Werte zu überprüfen.

Programmgesteuertes Kriterium (Programmatic-Criterion): Dieser Kriterientyp soll es ermöglichen, eine eigene Java-Klasse definieren zu können, die einen bestimmten Response auf Gültigkeit überprüft.

Schnappschuss-Kriterium (Screenshot-Criterion): Dieser Kriterientyp soll einen aufgenommenen und einen abgespielten Response mit Hilfe eines Bildvergleichs gegenüberstellen und als Ergebnis die unterschiedlichen Pixel liefern.

Differenz-Kriterium: Dieser Kriterientyp soll den Unterschied im HTML-Text eines aufgenommen und eines abgespielten Responses als Prozentwert liefern.

Diese Kriterientypen und andere geplante Erweiterungen werden allerdings erst nach einer erfolgreichen Validierung von Web-TEST bei der Firma MathConsult umgesetzt. Der Validierungsprozess ist voraussichtlich erst Ende 2009 fertig und ist daher nicht mehr Teil dieser Arbeit.

Erste Tests haben jedoch bereits gezeigt, dass die Erstellung und Verwaltung von Bedingungen durch Web-TEST vereinfacht wird. Probleme gibt es allerdings noch wenn konzeptionelle Änderungen in der SUT durchgeführt werden. Beispielsweise wurde bei der Entwicklung von UnRisk FACTORY Version 1.5 entschieden, dass nach dem Bestätigen einer Datenmanipulationsseite nicht mehr wie zuvor die dazugehörige Übersichtsseite sondern die entsprechende Detailseite gezeigt werden soll. Dadurch werden sehr viele Tests, die von vorhergehenden Versionen aufgezeichnet wurden, für die Version 1.5 ungültig und müssen Test für Test adaptiert werden.

Web-TEST hat weiters das Problem, dass zurzeit nur serverseitig generierte oder statische HTML-Seiten getestet werden können. Es ist beispielsweise nicht möglich eine auf JavaScript basierende Webanwendung zu testen. Diese Art von Anwendungen machen jedoch bereits einen Großteil der über das Internet verfügbaren Anwendungen aus. Deshalb ist es nicht zu erwarten, dass Web-TEST eine explosionsartige Verbreitung im Bereich des Testens von Internetanwendungen findet. Im Intranetbereich hingegen gibt es eine Vielzahl von Anwendungen die nur serverseitig generierte HTML-Seiten ausliefern und damit als Web-TEST-Kunden in Frage kommen.

6.1 Persönliche Schlussfolgerung

Die Erstellung von Tests und Testbedingungen mit Hilfe von Web-Test ist bereits sehr komfortabel. Die Probleme bei der Migration eines Tests von einer Version der SUT zur nächsten sind jedoch noch gravierend und hier gibt es noch Überarbeitungsbedarf. Helfen könnten hier zusätzliche Funktionen, die eine Art Refactoring der Testressource ermöglichen, beispielsweise die Umstellung von Zahlen- oder Datumsformate in allen Bedingungen, oder das Suchen und Ersetzten von Request-URLs mittels regulären Ausdrücken innerhalb einer Menge von Testressourcen.

Web-TEST muss sich mit großen Konkurrenten, wie etwa dem Rational-Functional-Tester vom IBM, messen und kann wahrscheinlich in Punkto Reife und Benutzerfreundlichkeit nicht mit diesen Werkzeugen mithalten. Dennoch bietet Web-TEST mit Hilfe der BA-Kriterien und deren automatische Generierung ein mächtiges Instrument zum Testen von HTML-basierten Webanwendungen, dessen Equivalent in keinem der getesteten Werkzeuge zu finden war. Außerdem sind die Web-TEST-Releases und der Web-TEST-Source-Code frei erhältlich und Web-TEST setzt klar auf Anpassbarkeit und Erweiterbarkeit. Diese drei Eigenschaften unterscheiden Web-TEST von allen anderen Testwerkzeugen für HTML-basierte Webanwendungen.

Der Autor sieht das eigentlichen Problem der Anwendung für eine größere Verbreitung dadurch gegeben, dass nur serverseitig generierte HTML-Seiten überprüft werden können. Bereits jetzt verwenden jedoch immer mehr Internet- und auch Intranetanwendungen AJAX (serverseitig generierte oder statische HTML-Seiten kombiniert mit JavaScript und XML) [39], um die HTML-Seiten zu generieren. Diese Entwicklung scheint sich auch auf lange Sicht aufgrund der besseren Benutzerfreundlichkeit durchzusetzen.

Ein logischer Schritt wäre es deshalb, Web-TEST in diese Richtung weiterzuentwickeln. Im Rahmen von UnRisk-FACTORY besteht jedoch zurzeit nicht der Bedarf nach dieser Erweiterung, weshalb andere Funktionserweiterungen noch vorrangig sind.

Literaturverzeichnis

Buch Referenzen

[1]	Automated Web Testing Toolkit Diane Stottlemyer, 2001, ISBN-10: 0471414352 John Wiley & Sons, Inc.
[2]	Testing Applications on the Web Hung Q. Nguyen, 2001, ISBN-10: 047139470X John Wiley & Sons, Inc.

Internet Referenzen

[3]	MathConsult GmbH Homepage Verfügbar unter: http://www.mathconsult.co.at/ [Freitag, 4. September 2009]
[4]	UnRisk Homepage Verfügbar unter: http://www.unrisk.com/ [Freitag, 4. September 2009]
[5]	IBM Rational Functional Tester Product Side Verfügbar unter: http://www-01.ibm.com/software/awdtools/tester/functional/ [Freitag, 4. September 2009]
[6]	NeoTys Homepage Verfügbar unter: http://www.neotys.com/ [Freitag, 4. September 2009]
[7]	Verisium vTest Product Side Verfügbar unter: http://www.verisium.com/products/vTest/index.html [Freitag, 4. September 2009]
[8]	Software Research eValid Product Side Verfügbar unter: http://www.soft.com/eValid/ [Freitag, 4. September 2009]
[9]	Apache JMeter Homepage Verfügbar unter: http://jakarta.apache.org/jmeter/ [Freitag, 4. September 2009]
[10]	BadBoy Homepage Verfügbar unter: http://www.badboy.com.au/ [Freitag, 4. September 2009]
[11]	Minq Software PureTest Product Side Verfügbar unter: http://www.minq.se/products/puretest/ [Freitag, 4. September 2009]
[12]	Solex Homepage Verfügbar unter: http://solex.sourceforge.net/ [Freitag, 4. September 2009]
[13]	TPTP (Test and Performance Tools Platform) Homepage Verfügbar unter: http://www.eclipse.org/tptp/ [Freitag, 4. September 2009]
[14]	Eclipse Public License (EPL) Verfügbar unter: http://www.eclipse.org/legal/epl-v10.html [Freitag, 4. September 2009]
[15]	Apache Ant Homepage Verfügbar unter: http://ant.apache.org/ [Freitag, 4. September 2009]
[16]	Eclipse Homepage Verfügbar unter: http://www.eclipse.org/ [Freitag, 4. September 2009]
[17]	HTTP/1.1 Spezifikation Verfügbar unter: http://www.w3.org/Protocols/rfc2616/rfc2616.html [Freitag, 4. September 2009]
[18]	HTML 4.01 Spezifikation Verfügbar unter: http://www.w3.org/TR/html401/ [Freitag, 4. September 2009]
[19]	XPath 2.0 Spezifikation Verfügbar unter: http://www.w3.org/TR/xpath20/ [Freitag, 4. September 2009]
[20]	TPTP Downloads Verfügbar unter: http://www.eclipse.org/tptp/home/downloads/?ver=4.5.1 [Freitag, 4. September 2009]
[21]	Eclipse 3.3 Update Manager Hilfe Verfügbar unter: http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/tasks-34.htm [Freitag, 4. September 2009]
[22]	Eclipse Rich Client Platform (RCP) Frequently Asked Questions Verfügbar unter: http://wiki.eclipse.org/RCP_FAQ [Freitag, 4. September 2009]
[23]	Eclipse Modeling Framefork (EMF) Frequently Asked Questions Verfügbar unter: http://wiki.eclipse.org/index.php/EMF-FAQ [Freitag, 4. September 2009]
[24]	Eclipse Test & Performance Tools Platform (TPTP) Project – Project Structure Verfügbar unter: http://www.eclipse.org/tptp/home/project_info/general/EclipseTPTPProjectStructure.pdf [Freitag, 4. September 2009]
[25]	Eclipse BIRT Homepage Verfügbar unter: http://www.eclipse.org/birt/phoenix [Freitag, 4. September 2009]
[26]	Common Base Event Specification Verfügbar unter: http://www.eclipse.org/tptp/platform/documents/resources/cbe101spec/CommonBaseEvent_SituationData_V1.0.1.pdf [Freitag, 4. September 2009]
[27]	TPTP Remote Agent Controller Installation Guide Verfügbar unter: http://www.eclipse.org/tptp/home/downloads/4.5.0/documents/installguide/InstallGuide45.html [Freitag, 4. September 2009]
[28]	TPTP-JUnit-Test Demonstration Verfügbar unter: http://www.eclipse.org/tptp/home/documents/tutorials/screencasts/tptpJunit.html [Freitag, 4. September 2009]
[29]	TPTP-Manual-Test Demonstration Verfügbar unter: http://www.eclipse.org/tptp/home/documents/tutorials/viewlets/v4.1/EW-MT/EW-MT/EW-MT_viewlet_swf.html [Freitag, 4. September 2009]
[30]	TPTP-URL-Test Demonstration Verfügbar unter: http://www.eclipse.org/tptp/home/documents/tutorials/viewlets/v4.1/EW-MT/EW-MT/EW-MT_viewlet_swf.html [Freitag, 4. September 2009]
[31]	TPTP-Automated-GUI-Test Demonstration Verfügbar unter: http://www.eclipse.org/tptp/home/documents/tutorials/viewlets/v4.1/EW-URLTest/EW-URLTest/EW-URLTest_viewlet_swf.html [Freitag, 4. September 2009]
[32]	UML 2.0 Testing Profile Specification Verfügbar unter: http://www.omg.org/cgi-bin/doc?formal/05-07-07 [Freitag, 4. September 2009]
[33]	UM 2.0 Infrastructur Specification Verfügbar unter: http://www.omg.org/docs/formal/09-02-04.pdf [Freitag, 4. September 2009]
[34]	UML 2.0 Superstructur Specification Seite und folgende Verfügbar unter: http://www.omg.org/docs/formal/09-02-02.pdf [Freitag, 4. September 2009]
[35]	TPTP Test Modell Dokumentation Verfügbar unter: http://www.eclipse.org/tptp/platform/documents/resources/models/index.htm [Freitag, 4. September 2009]
[36]	Htmlunit Homepage Verfügbar unter: http://htmlunit.sourceforge.net [Freitag, 4. September 2009]
[37]	Apache Log4j Homepage Verfügbar unter: http://logging.apache.org/log4j/1.2/index.html [Freitag, 4. September 2009]
[38]	Ostermiller-Utils Homepage Verfügbar unter: http://ostermiller.org/utils [Freitag, 4. September 2009]
[39]	AJAX Wikipedia Eintrag Verfügbar unter: http://en.wikipedia.org/wiki/Ajax_(programming) [Freitag, 4. September 2009]

Abbildungsverzeichnis

Abbildung 1.1: Unerkannter Fehler durch eine neue Version der Anwendung. 2

Abbildung 1.2: Zweispaltige Tabelle in UnRisk-FACTORY mit Attributen als Name-Wert-Paare 4

Abbildung 1.3: Geforderter Anwendungsfall für Web-TEST. 6

Abbildung 1.4: Objekteigenschaften einer Testvorlage und einer Testausführung in UnRisk Factory 8

Abbildung 2.1: Die Standard-Drei-Schichten-Webarchitektur 12

Abbildung 2.2: Das White-Box-Testing-Prinzip. 13

Abbildung 2.3: Das Black-Box-Testing-Prinzip. 14

Abbildung 3.1: About-Eclipse-SDK-Dialog mit Web-TEST-Icon. 19

Abbildung 3.2: About-Eclipse-SDK-Feature-Dialog für Web-TEST. 20

Abbildung 3.3: Feature-Plug-Ins-Dialog für Web-TEST. 20

Abbildung 3.4: Testen des Agent Controllers. 22

Abbildung 3.5: Konfigurieren des Agent Controllers. 23

Abbildung 3.6: Konfiguration des Browser für die Testaufnahme. 24

Abbildung 3.7: Der Proxy-Dienst zum Aufzeichnen von Testdaten. 24

Abbildung 3.8: Konfiguration des Proxies in Mozilla Firefox. 25

Abbildung 3.9: Content Filter 26

Abbildung 3.10: Die Recorder-Ansicht 28

Abbildung 3.11: Der Testaufzeichnungs-Wizard erste Seite. 29

Abbildung 3.12: Der Testaufzeichnungs-Wizard zweite Seite. 30

Abbildung 3.13: Verwendung der SUT während der Testaufzeichnung. 31

Abbildung 3.14: Der Assertion-Editor 33

Abbildung 3.15: Die Overview-Seite des Test-Editors. 35

Abbildung 3.16: Test-Editor-HTTP-Requests-Seite. 36

Abbildung 3.17: Test-Editor-Behavior-Seite. 37

Abbildung 3.18: Test-Editor-Ref.-Response-Overview-Seite. 39

Abbildung 3.19: Der hierarchische Aufbau von Assertions. 40

Abbildung 3.20: Die HTML-Browser-Seite des Test-Editors. 42

Abbildung 3.21: Der Automatic-Assertion-Generation-Dialog für eine Text-Assertion. 43

Abbildung 3.22: Aufbau der Assertion "Browser View Assertion 0" 43

Abbildung 3.23: Die DOM-Browser-Seite des Test-Editors. 44

Abbildung 3.24: Der Automatic-Assertion-Generation-Dialog für eine XPath-Assertion. 45

Abbildung 3.25: Die BA-Browser-Seite des Test-Editors nach Auswahl des Templates „UnRisk Detail Table Template“ 47

Abbildung 3.26: Der Automatic-Assertion-Generation-Dialog für eine BA-Assertion. 48

Abbildung 3.27: Konfiguration von BA-Templates. 50

Abbildung 3.28: Der BA-Assertion-Generation-Wizard. 51

Abbildung 3.29: Die Assertion-Overview-Seite des Assertion-Editors. 52

Abbildung 3.30 Die Text-Criterion-Seite des Assertion-Editors. 54

Abbildung 3.31: Die XPath-Criterion-Seite des Assertion-Editors. 55

Abbildung 3.32: Die BA-Criterion-Seite des Assertion-Editors. 56

Abbildung 3.33: Ändern des Werts des Currency-BAIs auf "USD" 58

Abbildung 3.34: Die Value-Selector-Seite des Assertion-Editors. 60

Abbildung 3.35: Der Automatic-Value-Selector-Generation-Dialog. 61

Abbildung 3.36: Die Value-Selector-Seite des Assertion-Editors mit den benötigen Value-Selectoren 62

Abbildung 3.37: Die Parameter-Seite des Assertion-Editors. 63

Abbildung 3.38: Die Package-Explorer-Ansicht des Projekts „Demo_WebTEST“. 65

Abbildung 3.39: Die Ausführung des Tests. 66

Abbildung 3.40: Das Testprotokoll im Testprotokoll-Editor 67

Abbildung 4.1: Die Zielgruppen und Verwendung von TPTP. 71

Abbildung 4.2: Eclipse Top-Level-Projekte (vergleiche [2] Seite 3) 73

Abbildung 4.3: Die Komponenten von TPTP (siehe [6] Seite 16) 74

Abbildung 4.4: Das TPTP-Execution-Environment (vergleiche dazu [19] auf Seite 30) 76

Abbildung 4.5: Der grafische Editor für TPTP-JUnit-Tests (siehe die Demonstration unter [28]) 80

Abbildung 4.6: Der Test-Editor für TPTP-Manual-Tests (siehe Demonstration unter [29]) 81

Abbildung 4.7: Die Manual-Test-Client-Anwendung für den Tester (siehe Demonstration unter [29]) 82

Abbildung 4.8: Der Editor für TPTP-URL-Tests (siehe Demonstration unter [30]) 83

Abbildung 4.9: Der Editor für TPTP-Automated-GUI-Tests (siehe Demonstration unter [12]) 85

Abbildung 4.10: TPTP-GUI-Recorder 85

Abbildung 4.11: Das Test-Modell 87

Abbildung 4.12: Grafische Darstellung eines UML-Sequenzdiagramm.. 89

Abbildung 4.13: Kernelemente des Behavior-Modells. 90

Abbildung 4.14: Ausschnitt aus den Elementen des Interaktionsoperand im Behavior-Modell 92

Abbildung 4.15: Kernelemente des Execution-History-Modells. 94

Abbildung 5.1: Integration von Web-TEST in TPTP. 98

Abbildung 5.2: Die Plug-Ins von Web-TEST. 99

Abbildung 5.3: Datenstruktur des Web-TEST-Tests „ShowModel_WebTEST“. 104

Abbildung 5.4: Instanzmodell - Testsuite Behavior-Modell 105

Abbildung 5.5: Instanzmodell - Testfälle und deren Behavior-Modell 107

Abbildung 5.6: Das „webtestData“ Datenmodell 108

Abbildung 5.7: Die Daten von „webtestData“ die im gezeigten Anwendungsfall erstellt wurden. 109

Abbildung 5.8: Der Datentyp Test-Value-Selector 110

Abbildung 5.9: Daten eines Test-Value-Selector-Elements. 111

Abbildung 5.10: Der Datentyp Test-Filled-Parameter 111

Abbildung 5.11: Daten eines Test-Filled-Parameter-Elements. 113

Abbildung 5.12: Der Datentyp XPath-Criterion. 113

Abbildung 5.13: Daten eines XPath-Criterion-Elements. 115

Abbildung 5.14: Der Datentyp Html-Criterion. 116

Abbildung 5.15: Daten eines Html-Criterion-Elements. 117

Abbildung 5.16: Der Datentyp Business-Attribute-Criterion. 117

Abbildung 5.17: Daten eines Business-Attriubte-Criterions. 119

Abbildung 5.18: Der Datentyp Assertion. 120

Abbildung 5.19: Daten einer Assertion. 121

Abbildung 5.20: Die in Web-TEST-UI erweiterten TPTP-Erweiterungspunkte. 122

Abbildung 5.21: Die Erweiterung des Erweiterungspunkts Testtyp-Beschreibung. 123

Abbildung 5.22: Die Erweiterung des Erweiterungspunkts Test-Editor-Beschreibung. 123

Abbildung 5.23: Die Erweiterung des Erweiterungspunkts Testcode-Generierungs-Wizard. 124

Abbildung 5.24: Die in Web-TEST-Core erweiterten TPTP-Erweiterungspunkte. 125

Abbildung 5.25: : Die Erweiterung des Erweiterungspunkts Test-Ausführungs-Komponente. 127

Abbildung 5.26: Der in Web-TEST-Core erweiterte TPTP-Erweiterungspunkt 129

Abbildung 5.27: Die Erweiterungen in Web-TEST-Models. 130

Abbildung 5.28: Speicherung von webtestData innerhalb der TPTP-Testressource. 131

Abbildung 5.29: Definition des Kriterium-Typs Business-Attriubte-Kriterium.. 132

Abbildung 5.30: Definition des Kriterium-Speichers für Business-Attriubte-Kriterien. 133

Abbildung 5.31: Die Schnittstelle org.eclipse.tptp.models.web.common.storage.ICriterionStorage 133

Abbildung 5.32: Die Erweiterungen in Web-TEST-Core. 134

Abbildung 5.33: Definition der Kriterium-Typ-Engine für das Business-Attriubte-Kriterium.. 134

Abbildung 5.34: Die Erweiterungen in Web-TEST-UI 135

Tabellenverzeichnis

Tabelle 3‑1: Die Werte der Request-Parameter für die Parameter „responseUID“ und „SUId“. 64

Tabelle 5‑1: Elemente und Attribute des Datentyps Test-Value-Selector 111

Tabelle 5‑2: Elemente und Attribute des Datentyps Test-Filled-Parameter 112

Tabelle 5‑3: Elemente und Attribute des Datentyps XPath-Criterion. 114

Tabelle 5‑4: Elemente und Attribute des Datentyps Criterion. 115

Tabelle 5‑5: Elemente und Attribute des Datentyps Html-Criterion. 116

Tabelle 5‑6: Elemente und Attribute des Datentyps Business-Attribute-Criterion. 118

Tabelle 5‑7: Elemente und Attribute des Datentyps Business-Attribute-Criterion. 121

Tabelle 5‑8: Erweiterungspunkt Test-Ausführungs-Komponente. 129

Curriculum Vitae

Name Günter Öller, Bakk.techn.

Geburtsdatum 15. Juli 1982

Staatsangehörigkeit Österreich

Adresse Leopold-Figl-Str. 46/1/2, 4040 Linz

Ausbildung und beruflicher Werdegang

aktuell Softwareentwickler bei der Firma MathConsult GmbH, Linz

2006 - 2009 Masterstudium der Informatik an der Johannes Kepler Universität, Linz

Jänner 2008 Auslandsemester an der Oxford Brookes University, Oxford

September 2006 Abschluss des Bakkalaureatsstudiums Informatik an der Johannes Kepler Universität, Linz

2005 – 2009 Softwareentwickler bei der Firma MathConsult GmbH, Linz

2003 – 2006 Bakkalaureatsstudium der Informatik an der Johannes Kepler Universität, Linz

2002 – 2003 Präsenzdienst beim österreichischen Bundesheer, Freistadt

Juni 2002 Matura an der HTBLA Leonding für EDV und Organisation, Leonding

1997 – 2002 HTBLA Leonding für EDV und Organisation, Leonding

1993 – 1997 Sporthauptschule Ulrichsberg, Ulrichsberg

Eidesstattliche Erklärung

Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe.

Linz, Juni 2009 Günter Öller